Java EE 7 behavior differences
When moving from Java EE 6 to Java EE 7, there might be some behavior differences in your application because of implementation changes and specification clarifications. In Liberty, you are not required to move to the next Java EE level and can continue to use the existing Java EE 6 features. In WebSphere Application Server traditional V9.0, only the JAX-RS and JPA technologies can remain at the Java EE 6 level, and you must explicitly configure them on the server. All other technologies must be migrated to the Java EE 7 level.
CDI 1.2
| Rule Name | Rule Description | Automated Fix |
|---|---|---|
| CDI recognizes implicit bean archives | The Contexts and Dependency Injection (CDI) 1.1 specification introduced implicit bean discovery mode, resulting in behavior and performance changes from the Java Platform, Enterprise Edition (Java EE) 6 CDI 1.0 implementation in WebSphere Application Server. | No |
| CDI scans for implicit beans when there is no beans.xml file | The Contexts and Dependency Injection (CDI) 1.1 specification introduced implicit bean discovery mode, resulting in behavior and performance changes from the Java Platform, Enterprise Edition (Java EE) 6 CDI 1.0 implementation in WebSphere Application Server. | No |
| Check for a behavior change in the InjectionPoint getAnnotated method | In the Contexts and Dependency Injection (CDI) 1.0 implementation, the getAnnotated method on a class that implements the
javax.enterprise.inject.spi.InjectionPoint interface can return an instance of javax.enterprise.inject.spi.Annotated.
In the CDI 1.2 implementation, the getAnnotated method must return an instance of AnnotatedField or
AnnotatedParameter, depending on whether the injection point is an injected field or a parameter on a constructor or method. |
No |
| Check for a valid schema in beans.xml | This rule scans the beans.xml files to see if the namespace provided in the xmlns attribute matches
the corresponding schema location. |
java-ee-7.yml org.openrewrite.java.migrate.BeansXmlNamespace |
| Check for a valid namespace in beans.xml | This rule scans the beans.xml files to see if a valid namespace is provided on the xmlns attribute. |
No |
| Check for the enablement of interceptors, decorators and alternatives in other JAR files | In the CDI 1.2 Weld implementation, Interceptors, decorators, and alternatives that are enabled in the beans.xml file in one JAR file are only enabled for that JAR file. | No |
| Classes that use both the Specializes and Alternative annotations are not injected into other modules | This rule flags classes that are annotated with both the @Specializes and @Alternative annotations. |
No |
| Do not use the OpenWebBeans schema for beans.xml | The OpenWebBeans schema for the beans.xml file is not supported in the Liberty CDI 1.2 implementation. |
java-ee-7.yml org.openrewrite.xml.liberty.WebBeansXmlRule |
| Producer fields on session beans must be static | In the CDI 1.2 Weld implementation, the application does not start and throws an exception when
non-static fields with the @Produces annotation are declared in session bean classes
|
java-ee-7.yml org.openrewrite.java.migrate.AddStaticVariableOnProducerSessionBean |
| The openwebbeans.properties file is not used | This rule flags META-INF/openwebbeans/openwebbeans.properties configuration files in your application. The Java EE 7 CDI 1.2 feature is based on the Weld reference implementation of CDI, which does not use this configuration file. | No |
| Transient fields in session-scoped beans cannot fail over successfully | This rule flags fields with the transient modifier in classes that are annotated with @SessionScoped. |
No |
EL 3.0
| Rule Name | Rule Description | Automated Fix |
|---|---|---|
| Behavior change in coerceToType method with null parameter | Expression Language 3.0 introduces a behavior change when a null
value is provided to the first parameter of coerceToType(Object obj, Class<?> targetType). |
No |
JAX-RS 2.0
| Rule Name | Rule Description | Automated Fix |
|---|---|---|
| @Local JAX-RS interfaces must be implemented | In the WebSphere Application Server Java Platform, Enterprise Edition (Java EE) 7 JAX-RS 2.0 implementation,
when JAX-RS interfaces are passed as values to the @javax.ejb.Local annotation, the class using
the annotation must implement the passed interfaces. |
No |
| Java API for RESTful Web Services (JAX-RS) and Contexts and Dependency Injection for Java (CDI) | This rule identifies the presence of JAX-RS and CDI in the application. WebSphere Application Server traditional V9.0, compliant with Java EE 7, comes with JAX-RS 2.0 by default but allows reverting to JAX-RS 1.1 if needed. | No |
| Configuration is required to use SSL in JAX-RS 2.0 | To use the JAX-RS 2.0 Secure Sockets Layer (SSL) function on your Liberty server, you must enable either the
ssl-1.0 feature or the appSecurity-2.0 feature
and configure the com.ibm.ws.jaxrs.client.ssl.config property in the JAX-RS 2.0 client code. |
No |
| org.codehaus.jackson packages are not available | The org.codehaus.jackson packages that are exposed as a third-party API in JAX-RS 1.1
are no longer exposed in the WebSphere Application Server Java Platform. |
No |
| Packaging Apache Wink APIs with your application might require application changes | When the Apache Wink APIs are packaged with the application, the application must provide a
subclass of javax.ws.rs.core.Application, and at least one of the getClasses()
and getSingletons() method implementations must not return null. |
No |
| The Apache Wink APIs are not available | The org.apache.wink packages are not available to Java API for RESTful Web Services (JAX-RS) applications that
use the WebSphere Application Server Java Platform, Enterprise Edition (Java EE) 7 JAX-RS 2.0 implementation. |
No |
| The Apache Wink Client APIs are not available | The org.apache.wink.client packages are not available to JAX-RS applications that
use the WebSphere Application Server Java Platform, Enterprise Edition (Java EE) 7 JAX-RS 2.0 implementation. |
No |
| The com.ibm.websphere.jaxrs.server.IBMRestFilter class is no longer supported | The com.ibm.websphere.jaxrs.server.IBMRestFilter APIs are not available in the WebSphere Application Server
Java Platform, Enterprise Edition (Java EE) 7 JAX-RS 2.0 implementation because they are based on the JAX-RS 1.1 Wink implementation. |
No |
| The org.apache.wink.client.handlers.LtpaAuthSecurityHandler class is no longer supported | The org.apache.wink.client.handlers.LtpaAuthSecurityHandler APIs are not available to
Java API for RESTful Web Services (JAX-RS) applications that use the WebSphere Application Server Java Platform,
Enterprise Edition (Java EE) 7 JAX-RS 2.0 implementation because they are based on the JAX-RS 1.1 Wink implementation. |
No |
| The org.apache.wink.common.model.atom package is not available | The org.apache.wink.common.model.atom package is not available to Java API for RESTful Web Services
(JAX-RS) applications that use the WebSphere Application Server Java Platform, Enterprise Edition (Java EE) 7
JAX-RS 2.0 implementation. |
No |
| The org.apache.wink.common.model.multipart package is not available | In the WebSphere Application Server Java Platform, Enterprise Edition (Java EE) 7 JAX-RS 2.0 implementation,
the org.apache.wink.common.model.multipart package was replaced with the
com.ibm.websphere.jaxrs20.multipart package from IBM. |
No |
| Use the isReadable and isWriteable methods to check the media type | In the WebSphere Application Server Java Platform, Enterprise Edition (Java EE) 7 JAX-RS 2.0 implementation,
MessageBodyReader and MessageBodyWriter interfaces with @Consumes and @Produces annotations
might restrict the media types that they support. |
No |
JMS Client 2.0
| Rule Name | Rule Description | Automated Fix |
|---|---|---|
| Check for a behavior change on message priority and the NoLocal attribute | JAXB and XML Binding prior to 4.0 provide the deprecated Validator class.
This class is unavailable in XML Binding 4.0 as on-demand validation is no longer supported. |
No |
| Check for a behavior change on setClientID and createDurableSubscriber methods | This rule flags the javax.jms.Session.createDurableSubscriber, javax.jms.TopicSession.createDurableSubscriber,
and javax.jms.Connection.setClientID methods because they throw different exceptions in JMS Client 2.0. |
No |
Servlet 3.1
| Rule Name | Rule Description | Automated Fix |
|---|---|---|
| Check for a behavior change in the processing of the absolute-ordering element | In Servlet 3.0, if the metadata-complete attribute is set to "true", all web fragment archives are used regardless of whether they are referenced in the <absolute-ordering> element in the web.xml file. In Servlet 3.1, web fragments that are not listed in the <absolute-ordering> element are excluded from processing. | No |
| Check for a behavior change on asynchronous servlets | In Servlet 3.0, if a query string is included with a request, this string is made available to the dispatched resource. In Servlet 3.1, if a query string is provided to the dispatching resource, this query string is made available to the dispatched resource instead of the query string from the original request. | No |
| Check for a behavior change on the getServerInfo method | This rule flags references to the javax.servlet.ServletContext.getServerInfo() method because the Servlet 3.1 feature implementation returns a different value than the Servlet 3.0 feature implementation. | No |
| Check for a behavior change on the sendRedirect method | This rule flags references to the javax.servlet.http.HttpServletResponse.sendRedirect(String) method because the default behavior for relative URLs is different in the Servlet 3.1 feature implementation than in the Servlet 3.0 implementation. | No |
| Check for a behavior change on the ServletContextListener interface | Classes that implement the javax.servlet.ServletContextListener interface must either be annotated with the javax.servlet.annotation.WebListener annotation or be defined as a listener-class in the web.xml or web-fragment.xml file. | No |
| Check for a behavior change on the setComment method | This rule flags references to the javax.servlet.SessionCookieConfig.setComment() method because the Servlet 3.1 feature implementation throws an IllegalStateException after the servlet context initializes, whereas Servlet 3.0 does not. | No |
| Check for a behavior change regarding duplicate elements in web descriptors | In Servlet 3.0, an application can be deployed even if the web descriptors contain duplicate <ordering> or <absolute-ordering> elements. In Servlet 3.1, an application with these duplicate elements cannot be deployed. | No |
| Check for a behavior change with resource reference injection target merging | The resource reference injection target merging behavior is different in the Servlet 3.1 feature implementation than in the Servlet 3.0 implementation. Existing application behavior might change because of newly activated injection targets defined in the web-fragment.xml file that were previously excluded from the web.xml file. | No |
| Check for a behavior change with URL pattern mapping | In Servlet 3.0, an application will start successfully even if the same URL pattern is mapped to multiple servlets. In Servlet 3.1, the application does not start and throws an exception. | No |
| Check for new methods that were added to javax.servlet.ServletOutputStream and javax.servlet.ServletInputStream | Servlet 3.1 introduces new methods in javax.servlet.ServletOutputStream and javax.servlet.ServletInputStream. These methods were not included in Servlet 3.0 and must be implemented when migrating to Servlet 3.1. | No |
OpenJPA to EclipseLink JPA
| Rule Name | Rule Description | Automated Fix |
|---|---|---|
| Disable the persistence unit second-level cache | OpenJPA disables the second-level cache by default, whereas EclipseLink enables it by default. Use the quick fix to modify the persistence unit cache configuration to maintain the same caching behavior in EclipseLink. |
java-ee-7.yml org.openrewrite.java.migrate.JpaCacheProperties |
| Do not use OpenJPA providers in the persistence.xml file | Use the default JPA provider instead of an OpenJPA specific provider when migrating from OpenJPA to EclipseLink. |
java-ee-7.yml org.openrewrite.java.migrate.javaee7.OpenJPAPersistenceProvider |
| Do not use OpenJPA strings for query hints or properties | The OpenJPA defined strings used for query hints and properties must be replaced with an EclipseLink equivalent where available. | No |
| OpenJPA to EclipseLink information and potential issues | This rule contains general information for migrating to Java EE 7 (OpenJPA), as well as information on issues that the WebSphere Migration Toolkit for Application Binaries (binary scanner) does not detect. |
java-ee-7.yml org.openrewrite.java.migrate.javax.openJPAToEclipseLink |
| The openjpa.LockManager configuration property must be migrated | The OpenJPA LockManager property, openjpa.LockManager, must be migrated using a JPA 2.1 specification provided lock API. | No |
| The openjpa.jdbc.Schema configuration property must be migrated to the mapping file | The OpenJPA schema property, openjpa.jdbc.Schema, must be migrated to the specification-defined mapping file configuration. | No |
| The org.apache.openjpa.enhance.PersistenceCapable interface is not available | The org.apache.openjpa.enhance.PersistenceCapable interface, which is inserted at build time, is not available to JPA applications that use the WebSphere traditional or Liberty Java EE 7 JPA 2.1 implementation |
No |
| org.apache.openjpa packages are not available | The org.apache.openjpa JPA APIs are not available in the WebSphere Java EE 7 JPA 2.1 implementation. | No |
| Mapping files are not processed during OpenJPA to EclipseLink migration | The OpenJPA to EclipseLink Migration rule set migrates issues found in JPA annotations but does not migrate issues in entity mapping files. | No |
| OpenJPA and WebSphere JPA configuration properties must be migrated | OpenJPA and WebSphere vendor-specific JPA 2.0 configuration properties must be migrated. Use standardized and EclipseLink properties instead. | No |