was8 spring5
1.0.0
Artikel und begleitendes Codeprojekt gehen Sie über die Methode zur Überwindung von Hindernissen, die auf den Frühling 5- und Spring -Boot 2 -Anwendungen in einem Anwendungscontainer von WebSphere 8.5 (WOS) überwunden werden. Die Probleme treten auf, wenn der Frühling aktualisierte Validierungsgläser verwendet und standardmäßig eine übergeordnete Ladestrategie für übergeordnete Klasse verwendet hat, die einem Upgrade im Wege stehen würde.
Insbesondere werden mehrere Optionen zur Änderung des Klassenladers zur Verwendung von übergeordnetem übergeordnetem zuletzt vorgestellt. Darüber hinaus rufen wir die spezifischen Gläser auf, die für den Feder- und Federschuh in einem Beispiel -JSP -Projekt in Ihrem Maven pom.xml benötigt werden.
Mit diesen Änderungen wird erwartet, dass Sie zu einer unterstützten Version von Spring migrieren können, während Sie Ihre Investition in 8,5 beträgt. Das ist, bis diese Produkte das Ende des Lebens erreichen.
Standardmäßig verwendet WebSphere Application Server 8.5.x (WAS8) die Lader -Strategie der Elternklasse. Im Allgemeinen lädt dies zuerst seine Version von Anwendungsserver (EE) -Gläsen und priorisieren sich vor dem, was in Ihrer Verteilung steht.
Beispielsweise haben Sie möglicherweise eine Version der Validierungs-API in Ihrem Web-Inf lib-Verzeichnis, aber der Klassenpfad wird die erste. Effektiv schatten Sie Ihre Version zugunsten der JEE-Version, mit der er geliefert wurde, war. Dies ist sinnvoll, IBM verbrachte viel Zeit damit, ihren Anwendungsserver mit einem bekannten Satz von Javax zu zertifizieren und zu testen.
Das Rub kommt, wenn Sie eine neuere Version von Spring 5.x und Spring Boot 2.x verwenden möchten. Diese Versionen verwenden und verlassen sich auf eine neuere Version von Javax Valtidation und Hibernate -Validierung für ihre Kernfunktionalität. Was machst du?
Option 1 besteht darin, Ihren Anwendungsserver zu aktualisieren. Dies ist mit Apache Tomcat, Open Liberty, JBoss und vielen anderen Open -Source -Implementierungen ziemlich einfach. Dies, weil eine große Herausforderung mit war. Viele kritische und ältere Anwendungen wurden seit Jahren 8,5 mit JDK 8.x betrieben, und das Unternehmen hat wenig Wunsch, einige teure Regressionstests zu bezahlen. Sicher Spring 4.x ist das Lebensende, aber es funktioniert immer noch. Warum also ein Upgrade? Die beste Antwort ist nicht, dass 5.x cooler ist und dass es meinem Lebenslauf hilft. Die wahre Antwort sind Schwachstellen. Sie werden nicht mehr unterstützt und das ist ein Problem, wenn, nicht wenn neue Schwachstellen in freier Wildbahn zu finden sind. Sie möchten diesem Szenario voraus sein.
Was war nicht 9? Nun, ich überlasse das dir. Persönlich, wenn Sie von 8 abmigrieren. Es sei denn, Sie haben einen sterbenden Bedarf an benutzerdefiniert. 8 Funktionen waren die oben genannten Open -Source -Implementierungen in Ordnung. Sie können so viele an so vielen Stellen einsetzen, wie Sie es in jeder Umgebung wünschen, Cloud. Container oder On-Prem. Ihre Wahl und Ihr CFO ist es egal.
Die Option, die wir hier ansprechen, besteht darin, den Klassenloader zuerst vom übergeordneten auf übergeordnete zuletzt zu wechseln. Dies ist keine langfristige Lösung. Dies bringt Sie nur zur Unterstützung des Frühlings und Ihr Unternehmen kann für diese Änderungen "Spring" "zum Frühling". Du verstehst es "Frühling", ich bin punny. Auch dies ist keine Silberkugel. Ich bin mir sicher, dass Ihre Infrastrukturteams in ihre Skripten investiert haben und gut laufende Knoten in stabilen Clustern haben. Die Bereitstellung eines neuen Knotens mit übergeordneten letzten kann sich auf andere Anwendungen auswirken, die nicht migrieren, sondern in derselben Zelle befinden. Was machst du dort?
Es gibt viele Möglichkeiten, diese Aufgabe zu erfüllen. Wir werden uns nicht mit diesen Einzelheiten befassen. Ich werde Ihnen drei (3) hohe Lösungen geben und Sie auswählen lassen.
Dies ist die riskanteste und am wenigsten dokumentierte. Hier aktualisieren Sie eine obskure XML -Datei in Ihrem Ohr mit iBM -spezifischen Anmerkungen und hoffen auf das Beste. Der Vorteil ist, dass Sie Ihre Skripte nicht ändern müssen. Der Nachteil? Ich war nicht in der Lage, dies in Produktionsumgebungen zu beweisen. Im Folgenden finden Sie einige Stapelüberlaufartikel zum Thema. Käufer achten Sie auf
Dieser funktioniert und funktioniert hervorragend mit Entwicklerversionen von IS oder wenn Sie Zugriff auf die WOS -Administratorkonsole haben. Diese Option ist eine großartige Möglichkeit, Ihre Änderungen nachzuweisen. Das Hauptproblem ist natürlich, dass diese Änderungen weder skalierbar sind noch geschrieben werden können. Möglicherweise gefallen Sie diese Option, aber es ist unwahrscheinlich, dass Ihre Infrastrukturteams Ihr Ohr nach jeder Modulbereitstellung gerne aktualisieren. Dies ist keine skable Option.
Dies ist wirklich Ihre einzige Option für die Produktion. Sie müssen mit Ihren Infrastrukturteams Hand in Hand zusammenarbeiten, um ihre Bereitstellungsskripte zu aktualisieren, um den Klassenloader während der Bereitstellung und vor dem Starten der Anwendung zu ändern. Ich habe die Jython -Datei (PY) eines Beispielentwicklers (dh nicht hoch getestet) aufgenommen, um Ihren Partnern den Punkt zu übermitteln.
Sie können meine Inspiration für das Jython -Skript von hier aus sehen
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" )Diese Veränderung ist total bei Ihnen. Sie benötigen einen Entwicklerserver oder einen lokalen Server, um Ihre Änderungen anzuzeigen und zu validieren. Sie müssen jedoch Ihre pom.xml mit spezifischen Änderungen für die Validierung und den Winterschlaf aktualisieren.
Nach Ihrem ersten Einsatz und nach dem Ändern des Klassenladers sehen Sie den folgenden Fehler in den Systemout -Protokollen:
Verursacht von: java.lang.classnotfoundException: javax.validation.parameternameProvider
Spring 5.x stützt sich auf Version 2.x des Validion-API, sodass Sie die API in Ihrem POM explizit aktualisieren müssen. Auch dies ist nur möglich, weil Sie den Klassenlader geändert haben. Ohne diese Änderung stecken Sie die Ladeversion 1.x aus dem Wot -Klassenpfad. Es gibt keine Arbeit. Es gibt andere Änderungen, wenn Sie JSP -Seiten verwenden. Siehe das Pom.xml im WAS8-War-Projekt.
Besonderer Hinweis Wenn Sie Tiles 2.x verwenden, müssen Sie auf Tiles 3.x aktualisieren. Das wird ein weiterer Beitrag.
< dependency >
< groupId >javax.validation</ groupId >
< artifactId >validation-api</ artifactId >
< version >2.0.1.Final</ version >
</ dependency >Obwohl es nicht spezifisch war, müssen wir die Abhängigkeit von Tomcat-Embed-Jasper einbeziehen, damit unsere Anwendung JSP-Seiten für lokales Laufen kompiliert und rendert. Nicht der Umfang ist auf die Bereitstellung gesetzt
< dependency >
< groupId >org.apache.tomcat.embed</ groupId >
< artifactId >tomcat-embed-jasper</ artifactId >
< version >${tomcat-embed-jasper.version}</ version >
< scope >provided</ scope >
</ dependency >In der Spring Boot 2.x Readme.md finden Sie die erforderlichen zusätzlichen Gläser.
Sie verwenden Java -Konfiguration, wenn Sie so weit gegangen sind. Vergessen Sie die XML -Konfiguration im alten Stil. Das war so Frühling 4.x. Du bist jetzt besser als das.
Bitte beachten Sie den Ort für die JSP-Seiten: /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 ;
}
}Wir erweitern den AbstractAnnotationConfigDispatcherServletinitializer, um auf die Schlüsselkonfiguration zuzugreifen. Warum? Wir können die Convenience -Kurse verwenden,
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 [] {
"/"
};
}
