Java EE 7-Verhaltensunterschiede
Bei der Migration von Java EE 6 auf Java EE 7 kann es aufgrund von Implementierungsänderungen und Spezifikationsklärungen zu einem geänderten Verhalten Ihrer Anwendung kommen. In Liberty ist keine Migration auf die neue Java EE-Version erforderlich. Sie können die vorhandenen Java EE 6-Features weiterhin verwenden. In WebSphere Application Server Traditional Version 9.0 können nur die JAX-RS- und JPA-Technologien auf dem Stand von Java EE 6 bleiben und Sie müssen sie explizit auf dem Server konfigurieren. Alle anderen Technologien müssen auf den Stand von Java EE 7 migriert werden.
CDI 1.2
| Regelname | Regelbeschreibung | Automatisierte Korrektur |
|---|---|---|
| CDI erkennt implizite Bean-Archive | Mit der CDI Version 1.1-Spezifikation (Contexts and Dependency Injection, Kontext- und Abhängigkeitsinjektion) wurde ein Modus für die Erkennung impliziter Beans eingeführt, der zu Änderungen in Bezug auf das Verhalten und die Leistung gegenüber der CDI Version 1.0 von Java Platform Enterprise Edition (Java EE) 6 in WebSphere Application Server geführt hat. | Nein |
| CDI sucht nach impliziten Beans, wenn keine Datei beans.xml vorhanden ist | Mit der CDI Version 1.1-Spezifikation (Contexts and Dependency Injection, Kontext- und Abhängigkeitsinjektion) wurde ein Modus für die Erkennung impliziter Beans eingeführt, der zu Änderungen in Bezug auf das Verhalten und die Leistung gegenüber der CDI Version 1.0 von Java Platform Enterprise Edition (Java EE) 6 in WebSphere Application Server geführt hat. | Nein |
| Prüfen, ob sich das Verhalten der InjectionPoint-Methode getAnnotated geändert hat | In der Contexts and Dependency Injection (CDI) 1.0-Implementierung kann die Methode
getAnnotatedin einer Klasse, die die Schnittstelle javax.enterprise.inject.spi.InjectionPoint implementiert,
eine Instanz von javax.enterprise.inject.spi.Annotated zurückgeben. In der CDI 1.2-Implementierung muss die Methode getAnnotated eine Instanz von
AnnotatedField oder AnnotatedParameter zurückgeben, je nachdem, ob der Injektionspunkt
ein eingefügtes Feld oder ein Parameter in einem Konstruktor oder einer Methode ist. |
Nein |
| Gültiges Schema in beans.xml suchen | Diese Regel durchsucht die beans.xml-Dateien, um festzustellen, ob der im Attribut xmlns angegebene Namespace mit dem entsprechenden Schemastandort übereinstimmt. |
java-ee-7.yml org.openrewrite.java.migrate.BeansXmlNamespace |
| Prüfung auf einen gültigen Namespace in beans.xml | Diese Regel durchsucht die beans.xml-Dateien, um zu sehen, ob ein gültiger Namespace für das Attribut xmlns angegeben ist. |
Nein |
| Prüfen, ob Interceptors, Decorators und Alternativen in anderen JAR-Dateien aktiviert sind | In der CDI 1.2 Weld-Implementierung sind Interceptoren, Dekoratoren und Alternativen, die in der beans.xml-Datei in einer JAR-Datei aktiviert sind, nur für diese JAR-Datei aktiviert. | Nein |
| Klassen, die die Annotationen Specializes und Alternative verwenden, werden nicht in andere Module eingefügt | Diese Regel markiert Klassen, die mit den Annotationen @Specializes und @Alternative annotiert sind. |
Nein |
| OpenWebBeans-Schema nicht für beans.xml verwenden | Das OpenWebBeans Schema für die beans.xml Datei wird von der Liberty CDI 1.2 Implementierung nicht unterstützt. | java-ee-7.yml org.openrewrite.xml.liberty.WebBeansXmlRule |
| Producer-Felder in Session-Beans müssen statisch sein | In der CDI-Implementierung 1.2 Weld startet die Anwendung nicht und löst eine Ausnahme aus, wenn nicht-statische Felder mit der @Produces-Annotation in Session-Bean-Klassen deklariert werden |
java-ee-7.yml org.openrewrite.java.migrate.AddStaticVariableOnProducerSessionBean |
| Datei openwebbeans.properties wird nicht verwendet | Diese Regel kennzeichnet META-INF/openwebbeans/openwebbeans.properties Konfigurationsdateien in Ihrer Anwendung. Das CDI Version 1.2-Feature von Java EE 7 basiert auf der Weld-Referenzimplementierung von CDI, die diese Konfigurationsdatei nicht verwendet. | Nein |
| Transiente Felder in sitzungsorientierten Beans können nicht erfolgreich übernommen werden | Diese Regel markiert Felder mit dem Modifikator transient in Klassen, die mit @SessionScoped annotiert sind. |
Nein |
EL 3.0
| Regelname | Regelbeschreibung | Automatisierte Korrektur |
|---|---|---|
| Geändertes Verhalten in der Methode coerceToType mit Nullparameter | Expression Language 3.0 führt eine Verhaltensänderung ein, wenn ein Nullwert im ersten Parameter von coerceToType(Object obj, Class<?> targetType) angegeben ist. |
Nein |
JAX-RS 2.0
| Regelname | Regelbeschreibung | Automatisierte Korrektur |
|---|---|---|
| @Local-JAX-RS-Schnittstellen müssen implementiert werden | Wenn in der JAX-RS 2.0-Implementierung von Java EE 7 in WebSphere Application Server JAX-RS-Schnittstellen als Werte an die Annotation
@javax.ejb.Local übergeben werden, muss die Klasse, die die Annotation verwendet, die übergebenen Schnittstellen implementieren. |
Nein |
| Java API for RESTful Web Services (JAX-RS) und Contexts and Dependency Injection for Java (CDI) | Diese Regel identifiziert das Vorhandensein von JAX-RS und CDI in der Anwendung. WebSphere Application Server die herkömmliche V9.0, die mit Java EE 7 konform ist, wird standardmäßig mit JAX-RS 2.0 ausgeliefert, ermöglicht aber bei Bedarf die Umstellung auf JAX-RS 1.1. | Nein |
| SSL kann in JAX-RS Version 2.0 erst nach der erforderlichen Konfiguration verwendet werden | Um die SSL-Funktion (Secure Sockets Layer) von JAX-RS 2.0 in Ihrem Liberty-Server verwenden zu können, müssen Sie entweder das Feature ssl-1.0 oder das Feature appSecurity-2.0
aktivieren und die Eigenschaft com.ibm.ws.jaxrs.client.ssl.config im JAX-RS 2.0-Client-Code konfigurieren. |
Nein |
| org.codehaus.jackson-Pakete sind nicht verfügbar | Die org.codehaus.jackson Pakete, die in JAX-RS 1.1 als API von Drittanbietern zur Verfügung stehen, sind in der WebSphere Application Server Java-Plattform nicht mehr verfügbar. |
Nein |
| Einschluss von Apache Wink-APIs in ein Anwendungspaket kann Anwendungsänderungen erfordern | Wenn die Apache Wink-APIs in ein Anwendungspaket eingeschlossen werden, muss die Anwendung eine Unterklasse von javax.ws.rs.core.Application bereitstellen und mindestens eine
der beiden Implementierungsmethoden getClasses() und getSingletons() darf nicht "null" zurückgeben. |
Nein |
| Apache Wink-APIs sind nicht verfügbar | Die org.apache.wink-Pakete sind für JAX-RS-Anwendungen (Java API for RESTful Web Services), die die JAX-RS 2.0-Implementierung von Java EE 7 in WebSphere Application Server verwenden, nicht verfügbar. |
Nein |
| Apache Wink-Client-APIs sind nicht verfügbar | org.apache.wink.client-Pakete stehen JAX-RS-Anwendungen, die die
JAX-RS 2.0-Implementierung von Java EE 7 in WebSphere Application Server verwenden, nicht zur Verfügung. |
Nein |
| Klasse com.ibm.websphere.jaxrs.server.IBMRestFilter wird nicht mehr unterstützt | com.ibm.websphere.jaxrs.server.IBMRestFilter-APIs sind in der JAX-RS 2.0-Implementierung von Java EE 7 in WebSphere Application Server nicht verfügbar, weil sie auf der JAX-RS 1.1-Wink-Implementierung basieren. |
Nein |
| Klasse org.apache.wink.client.handlers.LtpaAuthSecurityHandler wird nicht mehr unterstützt | Das org.apache.wink.client.handlers.LtpaAuthSecurityHandler-APIs sind für JAX-RS-Anwendungen (Java API for RESTful Web Services), die die JAX-RS 2.0-Implementierung von Java EE 7 in WebSphere Application Server verwenden, nicht verfügbar, weil sie auf der JAX-RS 1.1 Wink-Implementierung basieren. |
Nein |
| Paket org.apache.wink.common.model.atom ist nicht verfügbar | Das org.apache.wink.common.model.atom-Paket ist für JAX-RS-Anwendungen (Java API for RESTful Web Services), die die JAX-RS 2.0-Implementierung von Java EE 7 in WebSphere Application Server verwenden, nicht verfügbar. |
Nein |
| Paket org.apache.wink.common.model.multipart ist nicht verfügbar | In der JAX-RS 2.0-Implementierung von Java EE 7 in WebSphere wurde das org.apache.wink.common.model.multipart-Paket durch das com.ibm.websphere.jaxrs20.multipart-Paket von IBM ersetzt. |
Nein |
| Methoden isReadable und isWriteable zum Überprüfen des Medientyps verwenden | In der JAX-RS 2.0-Implementierung von Java EE 7 in WebSphere Application Server können MessageBodyReader- und MessageBodyWriter-Schnittstellen mit den Annotationen @Consumes
und @Produces die von ihnen unterstützten Medientypen einschränken. |
Nein |
JMS Client 2.0
| Regelname | Regelbeschreibung | Automatisierte Korrektur |
|---|---|---|
| Prüfen, ob sich das Verhalten in Bezug auf die Nachrichtenpriorität und das Attribut NoLocal geändert hat | JAXB und XML Binding vor Version 4.0 stellen die veraltete Klasse Validator bereit. Diese Klasse ist in XML Binding 4.0 nicht verfügbar, da die bedarfsgesteuerte Validierung nicht mehr unterstützt wird. |
Nein |
| Prüfen, ob sich das Verhalten der Methoden setClientID und createDurableSubscriber geändert hat | Diese Regel kennzeichnet die Methoden javax.jms.Session.createDurableSubscriber, javax.jms.TopicSession.createDurableSubscriber und javax.jms.Connection.setClientID, da sie im JMS-Client 2.0 unterschiedliche Ausnahmen auslösen. |
Nein |
Servlet 3.1
| Regelname | Regelbeschreibung | Automatisierte Korrektur |
|---|---|---|
| Prüfen, ob sich das Verhalten der Verarbeitung von absolute-ordering-Elementen geändert hat | Wenn in Servlet 3.0 das Attribut "metadata-complete" auf "true" gesetzt ist, werden alle Webfragment-Archive verwendet, unabhängig davon, ob sie im Element <absolute-ordering> in der Datei web.xml referenziert werden. In Servlet 3.1 werden Webfragmente, die nicht im Element <absolute-ordering> aufgeführt sind, von der Verarbeitung ausgeschlossen. | Nein |
| Prüfen, ob sich das Verhalten von asynchronen Servlets geändert hat | Wenn in Servlet 3.0 eine Abfragezeichenfolge in einer Anforderung enthalten ist, wird diese Zeichenfolge für die zugeteilte Ressource verfügbar gemacht. Wenn in Servlet 3.1 eine Abfragezeichenfolge für die zugeteilte Ressource bereitgestellt wird, wird diese Abfragezeichenfolge anstelle der Abfragezeichenfolge der ursprünglichen Anforderung für die zugeteilte Ressource verfügbar gemacht. | Nein |
| Prüfen, ob sich das Verhalten der Methode getServerInfo geändert hat | Diese Regel markiert Referenzen auf die Methode javax.servlet.ServletContext.getServerInfo(), da die Implementierung des Features Servlet 3.1 einen anderen Wert als die Implementierung des Features Servlet 3.0 zurückgibt. | Nein |
| Prüfen, ob sich das Verhalten der Methode sendRedirect geändert hat | Diese Regel markiert Referenzen auf die Methode javax.servlet.http.HttpServletResponse.sendRedirect(String), da sich das Standardverhalten für relative URLs in der Implementierung des Features Servlet 3.1 von dem in der Implementierung von Servlet 3.0 unterscheidet. | Nein |
| Prüfen, ob sich das Verhalten der Schnittstelle ServletContextListener geändert hat | Klassen, die die Schnittstelle javax.servlet.ServletContextListener implementieren, müssen entweder die Annotation javax.servlet.annotation.WebListener haben oder in der Datei web.xml oder web-fragment.xml als Listenerklasse definiert sein. | Nein |
| Prüfen, ob sich das Verhalten der Methode setComment geändert hat | Diese Regel markiert Referenzen auf die Methode javax.servlet.SessionCookieConfig.setComment(), da die Implementierung von Servlet 3.1 eine Ausnahme (IllegalStateException) auslöst, nachdem der Servlet-Kontext initialisiert wurde. Servet 3.0 tut dies nicht. | Nein |
| Prüfen, ob sich das Verhalten in Bezug auf doppelte Elemente in Webdeskriptoren geändert hat | In Servlet 3.0 kann eine Anwendung auch dann bereitgestellt werden, wenn die Webdeskriptoren doppelte <ordering> oder <absolute-ordering> Elemente enthalten. In Servlet 3.1 kann eine Anwendung mit diesen doppelten Elementen nicht implementiert werden. | Nein |
| Prüfen, ob sich das Verhalten durch die Zusammenführung von Ressourcenreferenz und Injektionsziel ändert | Das Verhalten der Zusammenführung von Ressourcenreferenz und Injektionsziel in der Implementierung des Features Servlet 3.1 unterscheidet sich von dem in der Implementierung von Servlet 3.0. Das momentane Anwendungsverhalten kann sich durch neu aktivierte Injektionsziele ändern, die in der Datei web.fragment.xml definiert werden und vorher aus der Datei web.xml ausgeschlossen waren. | Nein |
| Prüfen, ob sich das Verhalten mit URL-Musterzuordnungen geändert hat | In Servlet 3.0 wird eine Anwendung auch dann erfolgreich gestartet, wenn dasselbe URL-Muster mehreren Servlets zugeordnet ist. In Servlet 3.1 wird die Anwendung nicht gestartet, sondern eine Ausnahme ausgelöst. | Nein |
| Prüfen, ob javax.servlet.ServletOutputStream und javax.servlet.ServletInputStream neue Methoden hinzugefügt wurden | In Servlet 3.1 wurden neue Methoden in javax.servlet.ServletOutputStream und javax.servlet.ServletInputStream eingeführt. Diese Methoden sind in Servlet 3.0 nicht enthalten und müssen bei der Migration auf Servlet 3.1 implementiert werden. | Nein |
OpenJPA auf EclipseLink JPA
| Regelname | Regelbeschreibung | Automatisierte Korrektur |
|---|---|---|
| Second-Level-Cache der Persistenzeinheit inaktivieren | OpenJPA inaktiviert standardmäßig den Second-Level-Cache, wohingegen dieser von EclipseLink standardmäßig aktiviert wird. Verwenden Sie die Schnellkorrektur, um die Cachekonfiguration der Persistenzeinheit zu bearbeiten, damit dasselbe Caching-Verhalten auch in EclipseLink verwendet wird. | java-ee-7.yml org.openrewrite.java.migrate.JpaCacheProperties |
| Keine OpenJPA-Provider in der Datei persistence.xml verwenden | Verwenden Sie den Standard-JPA-Provider anstelle eines ObenJPA-spezifischen Providers, wenn Sie eine Migration von OpenJPA auf EclipseLink durchführen. | java-ee-7.yml org.openrewrite.java.migrate.javaee7.OpenJPAPersistenceProvider |
| Keine OpenJPA-Zeichenfolgen für Abfragehinweise oder -eigenschaften verwenden | Die für Abfragehinweise und -eigenschaften definierten OpenJPA-Zeichenfolgen müssen durch EclipseLink-Äquivalente ersetzt werden, sofern vorhanden. | Nein |
| OpenJPA auf EclipseLink Informationen und mögliche Probleme | Diese Regel enthält allgemeine Informationen zur Migration auf Java EE 7 ( OpenJPA ) sowie Informationen zu Problemen, die der WebSphere Migration Toolkit for Application Binaries (Binärscanner) nicht erkennt. | java-ee-7.yml org.openrewrite.java.migrate.javax.openJPAToEclipseLink |
| Konfigurationseigenschaft openjpa.LockManager muss migriert werden | Die OpenJPA-LockManager-Eigenschaft openjpa.LockManager muss mit einer von der JPA 2.1-Spezifikation unterstützten API für Sperren migriert werden. | Nein |
| Konfigurationseigenschaft openjpa.jdbc.Schema muss in die Zuordnungsdatei migriert werden | Die OpenJPA-Schemaeigenschaft openjpa.jdbc.Schema muss in die Konfiguration der Zuordnungsdatei migriert werden, die in der Spezifikation definiert ist. | Nein |
| Schnittstelle org.apache.openjpa.enhance.PersistenceCapable ist nicht verfügbar | Die Schnittstelle org.apache.openjpa.enhance.PersistenceCapable , die zur Erstellungszeit eingefügt wird, ist für JPA-Anwendungen, die die herkömmliche Implementierung WebSphere oder Liberty Java EE 7 JPA 2.1 verwenden, nicht verfügbar |
Nein |
| org.apache.openjpa-Pakete sind nicht verfügbar | Die org.apache.openjpa-JPA-APIs sind in der JPA 2.1-Implementierung von Java EE 7 in WebSphere nicht verfügbar. | Nein |
| Zuordnungsdateien werden bei der Migration von OpenJPA auf EclipseLink nicht verarbeitet | Der Regelsatz für die Migration von OpenJPA auf EclipseLink migriert Probleme in JPA-Annotationen, aber keine Probleme in Entitätszuordnungsdateien. | Nein |
| OpenJPA- und WebSphere-JPA-Konfigurationseigenschaften müssen migriert werden | Anbieterspezifische OpenJPA- und WebSphere-JPA-2.0-Konfigurationseigenschaften müssen migriert werden. Verwenden Sie stattdessen standardisierte und EclipseLink-Eigenschaften. | Nein |