was8 spring5
1.0.0
تتغلب المقالة ومشروع الرمز المصاحب على الطريقة التي يتغلب عليها العقبات التي تتم ترحيلها إلى تطبيقات تطبيق الربيع 5 و SPRING BOOT 2 في حاوية تطبيق WebSphere 8.5 (WAS). تنشأ المشكلات مع استخدام Spring مع مرورات التحقق من الصحة المحدثة وكانت افتراضيًا ، استخدم استراتيجية تحميل من الدرجة الأولى من الوالدين والتي من شأنها أن تقف في طريق الترقية.
على وجه التحديد ، يتم تقديم العديد من الخيارات حول كيفية تغيير محمل الفئة لاستخدام الأصل أخيرًا. بالإضافة إلى ذلك ، ندعو الجرار المحددة المطلوبة للبلاغ الربيع والربيع في مشروع JSP في عينة في Maven Pom.xml.
من المتوقع ، مع هذه التغييرات ، أن تتراجع إلى نسخة مدعومة من الربيع مع الحفاظ على استثمارك في 8.5. هذا حتى تصل هذه المنتجات إلى نهاية الحياة.
افتراضيًا ، يستخدم WebSphere Application Server 8.5.x (WAS8) استراتيجية Loader الفئة Parent_First. بشكل عام ، كانت هذه الوسائل ستقوم بتحميل إصدارها من الجرار خادم التطبيق (EE) أولاً وإعطاء الأولوية على ما هو موجود في التوزيع الخاص بك.
على سبيل المثال ، قد يكون لديك إصدار واحد من واجهة برمجة تطبيقات التحقق من الصحة في دليل الويب lib الخاص بك ، لكن مسار الفصل سيفضل أن يكون أولاً. ظل الظل بشكل فعال الإصدار الخاص بك لصالح إصدار JEE الذي جاء مع. هذا منطقي ، قضى IBM الكثير من الوقت في التصديق على خادم التطبيق الخاص بهم واختباره بمجموعة معروفة من Javax.* الجرار وتريد أن تبقيها على هذا النحو افتراضيًا.
يأتي RUB عندما تريد استخدام إصدار أحدث من Spring 5.x و Spring Boot 2.x وتستخدم تلك الإصدارات وتعتمد على إصدار أحدث من جافاكس التقييم والتحقق من صحة السبات لوظائفها الأساسية. ماذا تفعل؟
الخيار 1 هو ترقية خادم التطبيق الخاص بك. هذا مباشرة إلى الأمام مع Apache Tomcat و Open Liberty و JBoss والعديد من تطبيقات المصادر المفتوحة الأخرى. هذا لأن التحدي الكبير مع كان. كانت العديد من التطبيقات الحاسمة والإرثية التي تم تشغيلها هي 8.5 مع JDK 8.x لسنوات ، ولديها العمل القليل الرغبة في دفع بعض اختبارات الانحدار باهظة الثمن. من المؤكد أن الربيع 4.x هو نهاية الحياة ، لكنه لا يزال يعمل ، فلماذا ترقية؟ أفضل إجابة ليست أن 5.x أكثر برودة وأنه يساعد على سيرتي الذاتية. الجواب الحقيقي هو نقاط الضعف. لم تعد مدعومًا ، وهذه مشكلة عندما لا توجد ، لا توجد نقاط الضعف الجديدة في البرية. تريد أن تتقدم من هذا السيناريو.
ما لم يكن 9؟ حسنًا ، أترك هذا الأمر لك. شخصياً إذا كنت تهاجر بعيدًا عن 8. ما لم تكن لديك بعض الحاجة التي تحتاج إلى مخصصة ، فمن وظائف 8 ، فإن تطبيقات المصادر المفتوحة أعلاه ستعمل بشكل جيد. يمكنك نشر أكبر عدد تريده في العديد من الأماكن التي تريدها في أي بيئة ، سحابة. حاوية أو على أساس. اختيارك والمدير المالي الخاص بك لن يهتم.
الخيار الذي سنتعامل معه هنا هو مجرد تبديل جهاز التحميل من Parent أولاً إلى الوالد الأخير. هذا ليس حلًا طويل الأجل. هذا فقط يجعلك تدعم الربيع ويمكن لعملك "الربيع" لتلك التغييرات. يمكنك الحصول عليها "الربيع" ، أنا متعب. أيضا هذه ليست رصاصة فضية. أنا متأكد من أن فرق البنية التحتية الخاصة بك قد استثمرت في البرمجة النصية ولديها عقد جيدة في مجموعات مستقرة. قد يؤثر نشر عقدة جديدة مع الوالد الأخير على تطبيقات أخرى لا تهاجر ولكنها في نفس الخلية. ماذا تفعل هناك؟
هناك العديد من الطرق لإنجاز هذه المهمة. لن نتعمق في هذه التفاصيل. سأعطيك ثلاثة (3) حلول عالية المستوى وأسمح لك بالاختيار.
هذا هو الأكثر خطورة والأقل توثيق. هنا تقوم بتحديث بعض ملفات XML الغامضة في أذنك مع التعليقات التوضيحية الخاصة بـ IBM والأمل في الأفضل. الاتجاه الصعودي هو أنك لست بحاجة إلى تغيير البرامج النصية الخاصة بك. الجانب السلبي؟ لم أتمكن من إثبات أن هذا يعمل في بيئات الإنتاج. فيما يلي بعض المقالات المفرطة في هذا الموضوع. حذار المشتري
هذا واحد يعمل ويعمل بشكل رائع مع إصدارات المطورين من WAS أو إذا كان لديك وصول إلى وحدة التحكم في المسؤول. هذا الخيار هو وسيلة رائعة لإثبات تغييراتك. المشكلة الرئيسية بالطبع هي أن هذه التغييرات ليست قابلة للتطوير ولا يمكن نصها. قد يعجبك هذا الخيار ولكن من غير المرجح أن تقوم فرق البنية التحتية بتحديث أذنك بسعادة بعد كل عملية نشر في الوحدة النمطية. هذا ليس خيارًا قابلاً للنشر.
هذا هو حقا خيارك الوحيد للإنتاج. ستحتاج إلى العمل جنبًا إلى جنب مع فرق البنية التحتية الخاصة بك لتحديث البرامج النصية للنشر لتغيير جهاز التحميل أثناء النشر وقبل بدء التطبيق. لقد قمت بتضمين ملف مطور عينة (وهو ما يعني أنه لا تم اختباره بشكل كبير) ملف 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 الخاص بك مع تغييرات محددة للتحقق من صحة و hibernate.
بعد نشرك الأول ، وبعد تغيير محمل الفصل ، سترى الخطأ أدناه في سجلات Systemout:
سبب: java.lang.classnotfoundexception: javax.validation.parameternameprovider
يعتمد Spring 5.x على الإصدار 2.x من api-api ، لذا ستحتاج إلى ترقية واجهة برمجة التطبيقات بشكل صريح في POM. مرة أخرى ، هذا ممكن فقط لأنك غيرت محمل الفصل. بدون هذا التغيير ، فإنك عالق في الإصدار 1.x من مسار الفصل. لا يوجد عمل. هناك تغييرات أخرى إذا كنت تستخدم صفحات JSP. انظر pom.xml في مشروع WAS8-WAR.
ملاحظة خاصة إذا كنت تستخدم Tiles 2.x ، فستحتاج إلى الترقية إلى Tiles 3.x. سيكون ذلك منشورًا آخر.
< dependency >
< groupId >javax.validation</ groupId >
< artifactId >validation-api</ artifactId >
< version >2.0.1.Final</ version >
</ dependency >على الرغم من أنه لم يكن محددًا ، إلا أننا نحتاج إلى تضمين تبعية Tomcat-embed-Jasper للسماح لتطبيقنا بتجميع صفحات JSP وتقديمها للتشغيل المحلي. لا يتم تعيين النطاق على المقدمة
< 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 سنوات. أنت أفضل من ذلك الآن.
يرجى ملاحظة موقع صفحات 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 ;
}
}نحن نقوم بتوسيع نطاق AbstractAntAntationConfigDispatcherservletInitializer للوصول إلى تكوين المفتاح. لماذا؟ يمكننا استخدام فئات الراحة التي توفرها الربيع بدلاً من تكوين Dispatcherservlet و/أو 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 [] {
"/"
};
}
