was8 spring5
1.0.0
記事と付随するコードプロジェクトは、WebSphere 8.5（WAN）アプリケーションコンテナのSpring 5およびSpring Boot 2アプリケーションに移行する障害を克服する方法を介して進みます。 Springが更新された検証ジャーを使用しているため、問題は発生し、デフォルトでは、アップグレードの邪魔になる親のファーストクラスの読み込み戦略を使用していました。
具体的には、クラスローダーを変更して親を最後に使用する方法については、いくつかのオプションが表示されます。さらに、Maven POM.XMLのサンプルJSPプロジェクトで、春と春のブーツに必要な特定の瓶を呼び出します。
これらの変更により、投資を維持しながら8.5でした。それは、それらの製品が終末期に達するまでです。
デフォルトでは、WebSphere Application Server 8.5.X（WAS8）は、parent_firstクラスローダー戦略を使用します。一般に、これは、最初にアプリケーションサーバー（EE）のジャーのバージョンをロードし、配布の内容よりも優先順位を付けることでした。
たとえば、Web-Inf libディレクトリに1つのバージョンの検証APIがある場合がありますが、クラスパスは最初のものでした。効果的にバージョンをシャドウバンニングして、伴うJEEバージョンを支持していました。これは理にかなっています。IBMは、既知のJavaxのセットでアプリケーションサーバーの証明とテストに多くの時間を費やしました。
Spring 5.xおよびSpring Boot 2.xの新しいバージョンを使用すると、これらのバージョンがJavax ValtidationとCore機能のためにHibernate検証の新しいバージョンを使用して依存している場合に、Rubが発生します。職業はなんですか？
オプション1は、アプリケーションサーバーをアップグレードすることです。これは、Apache Tomcat、Open Liberty、JBoss、その他多くのオープンソースの実装でかなり簡単です。これは大きな挑戦だったからです。多くの重要なレガシーアプリケーションが実行されています。何年もJDK 8.xで8.5であり、ビジネスはいくつかの高価な回帰テストに支払うことを望んでいません。確かにSpring 4.xは終末期ですが、それでも機能します。なぜアップグレードするのですか？最良の答えは、5.xがより涼しく、履歴書に役立つということではありません。本当の答えは脆弱性です。あなたはもはやサポートされておらず、それは野生で新しい脆弱性が見つかった場合ではない場合に問題です。あなたはそのシナリオを先取りしたいです。
9ではなかったのですか？さて、私はそれをあなたに任せます。個人的には、あなたがから離れて移動している場合は8でした。カスタムの必要性が死にかけている場合を除き、上記のオープンソースの実装は正常に行われます。どんな環境でも、希望するだけの場所に必要なだけ多くを展開できます。クラウド。コンテナまたはオンプレム。あなたの選択とあなたのCFOは気にしません。
ここで対処するオプションは、クラスローダーを最初から親から親に最後に切り替えることです。これは長期的な解決策ではありません。これにより、春のサポートに到達するだけで、あなたのビジネスはその変化のために「春」することができます。あなたはそれを「春」にします、私はパニーです。また、これは銀の弾丸ではありません。あなたのインフラストラクチャチームがスクリプトに投資し、安定したクラスターでノードをうまく実行していると確信しています。最後の親で新しいノードを展開すると、移動していないが同じセルにある他のアプリケーションに影響する可能性があります。そこで何をしますか？
このタスクを達成するには多くの方法があります。これらの詳細を掘り下げません。私はあなたに3つの高レベルのソリューションを与えて、あなたに選ばせます。
これは最もリスクが高く、文書化されていないことです。ここでは、IBM固有の注釈で耳の不明瞭なXMLファイルを更新し、最高のものを期待してください。利点は、スクリプトを変更する必要がないことです。欠点？私はこれが生産環境で機能することを証明することができませんでした。以下は、トピックに関するいくつかのスタックオーバーフローの記事です。バイヤーは注意してください
これは、開発者バージョンのWASまたはWAS Admin Consoleにアクセスできる場合にうまく機能します。このオプションは、変更を証明するための優れた方法です。もちろん、これらの変更はスケーラブルではなく、スクリプト化できないことです。このオプションが好きかもしれませんが、インフラストラクチャチームがモジュールの展開ごとに喜んで耳を更新する可能性は低いです。これは科学的なオプションではありません。
これは本当に生産の唯一のオプションです。インフラストラクチャチームと協力して展開スクリプトを更新して、展開中およびアプリケーションを開始する前にクラスローダーを変更する必要があります。パートナーにポイントを獲得するために、サンプル開発者（これは高度にテストされていないことを意味する）Jython（PY）ファイルを含めました。
ここからJythonスクリプトの私のインスピレーションを見ることができます
print ( "Get Deployments : " )
deployments = AdminConfig . getid ( '/Deployment:' + APP_NAME + '/' )
print deployments
print ( "" )
print ( "Deployment Object" )
deploymentObject = AdminConfig . showAttribute ( deployments , 'deployedObject' )
print deploymentObject
myModules = AdminConfig . showAttribute ( deploymentObject , 'modules' )
myModules = myModules [ 1 : len ( myModules ) - 1 ]. split ( " " )
print myModules
for module in myModules :
if ( module . find ( 'WebModuleDeployment' ) != - 1 ):
AdminConfig . modify ( module , [[ 'classloaderMode' , 'PARENT_LAST' ]])
AdminConfig . save ()
print ( "Set module to PARENT_LAST" )この変更は完全にあなたにあります。変更を確認および検証するには、開発者サーバーまたはローカルサーバーが必要ですが、検証と冬眠用の特定の変更を使用してpom.xmlを更新する必要があります。
最初に展開した後、クラスローダーを変更した後、SystemOutログに以下のエラーが表示されます。
原因：java.lang.classnotfoundexception：javax.validation.parameternameprovider
Spring 5.xは、validtion-apiのバージョン2.xに依存しているため、POMのAPIを明示的にアップグレードする必要があります。繰り返しますが、これはクラスローダーを変更したためにのみ可能です。その変更がなければ、クラスパスからバージョン1.xをロードします。回避策はありません。 JSPページを使用している場合、他の変更があります。 WAS8-WARプロジェクトのpom.xmlを参照してください。
タイル2.xを使用している場合は、タイル3.xにアップグレードする必要があります。それは別の投稿になります。
< dependency >
< groupId >javax.validation</ groupId >
< artifactId >validation-api</ artifactId >
< version >2.0.1.Final</ version >
</ dependency >具体的ではありませんでしたが、アプリケーションがローカルランニング用にJSPページをコンパイルおよびレンダリングできるようにするために、Tomcat-embed-jasper依存関係を含める必要があります。スコープが提供されるように設定されていません
< dependency >
< groupId >org.apache.tomcat.embed</ groupId >
< artifactId >tomcat-embed-jasper</ artifactId >
< version >${tomcat-embed-jasper.version}</ version >
< scope >provided</ scope >
</ dependency >必要な追加の瓶については、Spring Boot 2.x readme.mdを参照してください。
ここまで行った場合は、Java Configを使用しています。古いスタイルのXML構成を忘れてください。それはとても春4.xでした。あなたは今それよりも優れています。
JSPページの場所に注意してください： /web-inf/views/
@ Configuration
@ EnableWebMvc
@ ComponentScan ( basePackages = { "org.scavino" })
public class AppConfig {
/**
* ViewResolver allows setting properties such as
* prefix (/WEB-INF/views/) or suffix (*.jsp) to the view name to generate
* the final view page URL. In our case this is how
* we will configure JSP pages.
*
* @return JSP resolver with prefix set to /WEB-INF/views/
*/
@ Bean
public InternalResourceViewResolver resolver () {
InternalResourceViewResolver resolver = new InternalResourceViewResolver ();
resolver . setPrefix ( "/WEB-INF/views/" );
resolver . setSuffix ( ".jsp" );
return resolver ;
}
}AbstractAnnotationConfigDisPatcherServletInitializerを拡張して、キー構成にアクセスできます。なぜ？ DispatcherServletおよび/またはContextLoaderListenerを手動で構成する代わりに、Springが提供する便利なクラスを使用できます
public class SpringMvcDispatcherServletInitializer extends AbstractAnnotationConfigDispatcherServletInitializer {
@ Override
protected Class <?> [] getRootConfigClasses () {
return null ;
}
@ Override
protected Class <?> [] getServletConfigClasses () {
return new Class [] {
AppConfig . class
};
}
@ Override
protected String [] getServletMappings () {
return new String [] {
"/"
};
}
