was8 spring5
1.0.0
Artikel dan proyek kode yang menyertainya membahas metode yang untuk mengatasi hambatan yang bermigrasi ke aplikasi Spring 5 dan Spring Boot 2 dalam wadah aplikasi WebSphere 8.5 (WAS). Masalah muncul karena Spring menggunakan stoples validasi yang diperbarui dan secara default menggunakan strategi pemuatan kelas satu orang tua yang akan menghalangi peningkatan.
Secara khusus, beberapa opsi disajikan tentang cara mengubah loader kelas untuk menggunakan orang tua terakhir. Selain itu, kami memanggil stoples spesifik yang diperlukan untuk boot musim semi dan musim semi dalam proyek JSP sampel di maven pom.xml Anda.
Diharapkan, dengan perubahan ini, Anda dapat bermigrasi ke versi musim semi yang didukung sambil mempertahankan investasi Anda adalah 8,5. Itu sampai produk -produk itu mencapai akhir kehidupan.
Secara default, WebSphere Application Server 8.5.x (WAS8) menggunakan strategi loader kelas parent_first. Secara umum ini berarti akan memuat versinya dari aplikasi server aplikasi (EE) terlebih dahulu dan memprioritaskan dirinya sendiri tentang apa yang ada dalam distribusi Anda.
Misalnya, Anda mungkin memiliki satu versi API validasi di direktori web-inf lib Anda, tetapi jalur kelas akan mendukung yang pertama. Bayangan bayangan yang efektif untuk versi JEE yang datang dengan itu. Ini masuk akal, IBM menghabiskan banyak waktu untuk mensertifikasi dan menguji server aplikasi mereka dengan satu set Javax yang diketahui.* Guci dan ingin tetap seperti itu secara default.
Gosok datang ketika Anda ingin menggunakan versi yang lebih baru dari Spring 5.x dan Spring Boot 2.x dan versi -versi itu digunakan dan mengandalkan versi javax valtidation dan validasi hibernasi yang lebih baru untuk fungsionalitas inti mereka. Apa pekerjaanmu?
Opsi 1 adalah untuk meningkatkan server aplikasi Anda. Ini agak lurus ke depan dengan Apache Tomcat, Open Liberty, JBoss dan banyak implementasi open source lainnya. Ini karena tantangan besar dengan adalah. Banyak aplikasi kritis dan warisan telah berjalan adalah 8.5 dengan JDK 8.x selama bertahun -tahun, dan bisnis ini memiliki sedikit keinginan untuk membayar beberapa pengujian regresi yang mahal. Tentu Spring 4.x adalah akhir kehidupan, tetapi masih berfungsi, jadi mengapa meningkatkan? Jawaban terbaik bukanlah 5.x lebih keren dan membantu resume saya. Jawaban sebenarnya adalah kerentanan. Anda tidak lagi didukung dan itu adalah masalah ketika, bukan jika, kerentanan baru ditemukan di alam liar. Anda ingin maju dari skenario itu.
Apa yang bukan 9? Baik aku menyerahkannya padamu. Secara pribadi jika Anda bermigrasi adalah 8. Kecuali jika Anda memiliki beberapa kebutuhan sekarat untuk kebiasaan adalah 8 fungsionalitas, implementasi open source di atas akan baik -baik saja. Anda dapat menggunakan sebanyak yang Anda inginkan di banyak tempat seperti yang Anda inginkan di lingkungan apa pun, cloud. wadah atau on-prem. Pilihan Anda dan CFO Anda tidak akan peduli.
Opsi yang akan kita atasi di sini adalah hanya mengganti ClassLoader dari Parent First ke Parent Last. Ini bukan solusi jangka panjang. Ini hanya membuat Anda mendukung musim semi dan bisnis Anda dapat "musim semi" untuk perubahan itu. Anda mendapatkannya "Musim Semi", saya menjadi Punny. Juga ini bukan peluru perak. Saya yakin tim infrastruktur Anda telah berinvestasi dalam skrip mereka dan memiliki node yang berjalan dengan baik di kelompok yang stabil. Menyebarkan simpul baru dengan orang tua yang lalu dapat mempengaruhi aplikasi lain yang tidak bermigrasi tetapi berada di sel yang sama. Apa yang kamu lakukan di sana?
Ada banyak cara untuk menyelesaikan tugas ini. Kami tidak akan mempelajari spesifik itu. Saya akan memberi Anda tiga (3) solusi tingkat tinggi dan membiarkan Anda memilih.
Ini adalah yang paling berisiko dan paling tidak terdokumentasi. Di sini Anda memperbarui beberapa file XML yang tidak jelas di telinga Anda dengan anotasi spesifik IBM dan berharap yang terbaik. Keuntungannya adalah Anda tidak perlu mengubah skrip Anda. Kelemahannya? Saya belum dapat membuktikan bahwa ini berfungsi di lingkungan produksi. Di bawah ini adalah beberapa artikel tumpukan overflow tentang topik tersebut. Pembeli berhati -hatilah
Yang ini bekerja dan bekerja sangat baik dengan versi pengembang dari WAS atau jika Anda memiliki akses ke konsol Admin. Opsi ini adalah cara yang bagus untuk membuktikan perubahan Anda. Masalah utama tentu saja adalah perubahan ini tidak dapat diskalakan dan tidak dapat ditulis. Anda mungkin menyukai opsi ini tetapi tidak mungkin tim infrastruktur Anda akan dengan senang hati memperbarui telinga Anda setelah setiap penerapan modul. Ini bukan opsi scable.
Ini benar -benar satu -satunya pilihan Anda untuk produksi. Anda perlu bekerja sama dengan tim infrastruktur Anda untuk memperbarui skrip penyebaran mereka untuk mengubah classloader selama penyebaran dan sebelum memulai aplikasi. Saya telah memasukkan file sampel pengembang (yang berarti tidak sangat diuji) Jython (PY) untuk menyampaikan poin ke mitra Anda.
Anda dapat melihat inspirasi saya untuk skrip Jython dari sini
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" )Perubahan ini benar -benar pada Anda. Anda akan memerlukan server pengembang atau server lokal untuk melihat dan memvalidasi perubahan Anda, tetapi Anda perlu memperbarui pom.xml Anda dengan perubahan spesifik untuk validasi dan hibernasi.
Setelah pertama Anda menggunakan, dan setelah mengubah loader kelas, Anda akan melihat kesalahan di bawah ini di log Systemout:
Disebabkan oleh: java.lang.classnotfoundException: javax.validation.parameternameprovider
Spring 5.x bergantung pada versi 2.x dari Validtion-API sehingga Anda perlu secara eksplisit meningkatkan API di POM Anda. Sekali lagi ini hanya mungkin karena Anda mengubah loader kelas. Tanpa perubahan itu, Anda macet memuat versi 1.x dari jalur kelas WS. Tidak ada kerja. Ada perubahan lain jika Anda menggunakan halaman JSP. Lihat pom.xml dalam proyek WAS8-WAR.
Catatan Khusus Jika Anda menggunakan ubin 2.x Anda harus meningkatkan ke ubin 3.x. Itu akan menjadi posting lain.
< dependency >
< groupId >javax.validation</ groupId >
< artifactId >validation-api</ artifactId >
< version >2.0.1.Final</ version >
</ dependency >Meskipun tidak spesifik, kita perlu memasukkan ketergantungan tomcat-embed-jasper untuk memungkinkan aplikasi kita mengkompilasi dan membuat halaman JSP untuk berjalan lokal. Bukan ruang lingkup yang disediakan
< dependency >
< groupId >org.apache.tomcat.embed</ groupId >
< artifactId >tomcat-embed-jasper</ artifactId >
< version >${tomcat-embed-jasper.version}</ version >
< scope >provided</ scope >
</ dependency >Lihat Spring Boot 2.x ReadMe.MD untuk stoples tambahan yang diperlukan.
Anda menggunakan java config jika Anda telah melangkah sejauh ini. Lupakan konfigurasi XML gaya lama. Itu sangat musim semi 4.x. Anda lebih baik dari itu sekarang.
Harap perhatikan lokasi untuk halaman 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 ;
}
}Kami memperluas AbstractAnnotationConfigDispatcherServletInitializer untuk memiliki akses ke konfigurasi utama. Mengapa? Kita dapat menggunakan kelas kenyamanan yang disediakan oleh Spring alih -alih secara manual mengkonfigurasi DispatcherServlet dan/atau ContextLoaderListener
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 [] {
"/"
};
}
