openliberty.websphere.liberty-java-unavailable-technologies.windup.xml Maven / Gradle / Ivy
The newest version!
This ruleset identifies usage of Java APIs and technologies which are not provided by Open Liberty.
<div class="Text"> <span class="SubHeader">Java EE Application Deployment API</span>
<p> This rule flags Java code that references the <code>javax.enterprise.deploy</code> package. </p>
<p> The Java EE Application Deployment API is not supported on Liberty or Liberty Core. The technology is deprecated in WebSphere Application Server traditional V9.0. If your application uses the Java EE Application Deployment API, you can deploy this part of your application on WebSphere Application Server traditional but the capability might be removed in a later version. </p>
<p> Use another way to deploy applications to the server, such as wsadmin scripting and JMX MBeans. The closest method to using the Java EE Deployment API is to use WebSphere JMX MBeans. For more information, see <a href="https://www.ibm.com/support/knowledgecenter/SSAW57_9.0.5/com.ibm.websphere.nd.multiplatform.doc/ae/crun_app_install.html" title="Opens a new window" onclick="javascript:helpWindow('https://www.ibm.com/support/knowledgecenter/SSAW57_9.0.5/com.ibm.websphere.nd.multiplatform.doc/ae/crun_app_install.html');return false"> Ways to install enterprise applications or modules. </a> </p>
<p> For Liberty, see <a href="https://www.ibm.com/docs/en/was-liberty/base?topic=SSEQTP_liberty/com.ibm.websphere.wlp.nd.multiplatform.doc/ae/twlp_dep.html" title="Opens a new window" onclick="javascript:helpWindow('https://www.ibm.com/docs/en/was-liberty/base?topic=SSEQTP_liberty/com.ibm.websphere.wlp.nd.multiplatform.doc/ae/twlp_dep.html');return false"> Deploying applications in Liberty. </a> </p>
</div>
<div class="Text">
<p> This rule flags Java code that has references to the following packages: </p>
<ul>
<li><code>javax.portlet</code></li>
<li><code>javax.portlet.filter</code></li>
</ul>
<p>This rule also flags the following references in the portlet.xml file: </p>
<ul>
<li><code><portlet-app></portlet-app></code></li>
</ul>
<p>The Java Portlet API and its deployment descriptors are not supported on Liberty. Deploy this part of your application on WebSphere Application Server traditional. </p>
</div>
<div class="Text"> <span class="SubHeader">Java API for XML Registries (JAXR)</span>
<p> This rule flags Java code that has references to the following packages: </p>
<ul>
<li><code>javax.xml.registry</code></li>
<li><code>javax.xml.registry.infomodel</code></li>
</ul>
<p>The Java API for XML Registries (JAXR) is not supported on Liberty or Liberty Core. The API is deprecated in WebSphere Application Server traditional V9.0. If your application uses the JAXR API, you can deploy this part of your application on WebSphere Application Server traditional but the capability might be removed in a later version. It is recommended to migrate to using UDDI Version 3 to replace JAXR technologies. </p>
</div>
<div class="Text">
<p>The OSGI repository service APIs is not supported in Liberty or Liberty Core.</p>
<p>This rule flags java references to APIs in the <code>org.osgi.service.repository</code> package.</p>
</div>
<div class="Text">
<p>The OSGI Remote Service Admin is not supported in Liberty or Liberty Core.</p>
<p>This rule flags java references to APIs in the <code>org.osgi.service.remoteserviceadmin</code> package.</p>
</div>
<div class="Text">
<p> This rule flags Java code that has references to the <code>org.oasis_open.docs.wsn</code> package. </p>
<p>This rule also flags the following references in WSDL files: </p>
<ul>
<li><code><import location="http://docs.oasis-open.org/wsn/*.wsdl"></import></code></li>
</ul>
<p>Web Services Notification (WS-Notification) is not supported on Liberty or Liberty Core. If your application uses WS-Notification, you can deploy this part of your application on WebSphere Application Server traditional. </p>
</div>
<div class="Text"> <span class="SubHeader">Entity Enterprise JavaBeans (EJB)</span>
<p> This rule flags <code>entity</code> elements in <span class="FilePath">ejb-jar.xml</span> files. </p>
<p> Entity beans are optional in the EJB 3.2 specification and are not supported on Liberty or Liberty Core. The entity bean API is deprecated in WebSphere Application Server traditional V8.5.5 and V9.0 and might be removed in a later version.</p>
<p> The EJBDeploy tool used to deploy applications with entity beans has also been deprecated and may be removed in the future, either at the same time entity beans are removed or prior. </p>
<p>The Java Persistence API (JPA) is an alternative to using EJB entity beans for new database and other persistence-related operations. </p>
<p> Upgrading entity beans can be difficult, but it can be simplified if your application uses design patterns such as DTO, Session Facade, and DAO. </p>
</div>
<div class="Text">
<p> Liberty does not support outbound or inbound transaction propagation for EJB remote interfaces. By default, EJB beans are container-managed and use the <code>Required</code> transaction attribute. As a result, existing EJB definitions that do not specify any <code>container-transaction</code> properties are configured by default to use transactions although they are not supported. </p>
<p>This rule flags Java code that references the following EJB annotations that indicate the use of remote business or home interfaces:</p>
<ul>
<li><code>javax.ejb.Remote</code></li>
<li><code>javax.ejb.RemoteHome</code></li>
</ul>
<p>This rule also flags the following references in the <span class="FilePath">ejb-jar.xml</span> file:</p>
<ul>
<li><code><remote/></code></li>
<li><code><business-remote/></code></li>
</ul>
<p> The EJB specification requires products that support outbound transaction propagation to still send a null transaction context. This context must be rejected by EJB components that use the <code>Required</code> (default), <code>Mandatory</code> , or <code>Supports</code> transaction attributes. A client with an active global transaction cannot start an EJB bean with default transaction attributes if either the client or server is on Liberty. </p>
<p> To enable the client to start the EJB bean, change the EJB bean to use either the <code>RequiresNew</code> or <code>NotSupported</code> transaction attribute. Although these attributes will allow the EJB bean to start, the transactional work that is done by the EJB bean is not committed as part of the client transactions. </p>
<p> Note that transaction propagation is supported for EJB remote interfaces that are running in the same JVM, however this may only be determined with further investigation of the application behavior. </p>
<h4>Make sure remote EJB interfaces are needed</h4>
<p> Often EJB 2.x beans configure the remote interfaces in ejb-jar.xml even when they are not used. You only need remote interfaces if you have code running across two different JVMs. In WebSphere terms, this is either between two different application servers or between a client application and an application server running in different JVMs. CORBA information, such as an <code>iiop://</code> provider URL, in an EJB lookup is also an indicator that remote EJB beans are being used. </p>
<p> If you are referencing EJB beans using a remote interface that are running in the same JVM, the Local interface can be used and will perform better. Where possible, change annotations from @Remote to @Local and from @RemoteHome to @LocalHome and test all your code scenarios. Likewise for ejb-jar.xml configuration, remove the <code><remote/></code> and <code><business-remote/></code> definitions and test all scenarios. While transaction propagation is supported for this scenario, the best practice is to convert to using local interfaces to improve performance and remove the perception that methods can be called externally from the same JVM. </p>
<h4>If you really need remote interfaces</h4>
<h5>Wrap the EJB beans in a web service (JAX-WS)</h5>
<p> For those EJB beans that require remote access, best practice is to wrap them in a web service. Refer to <a href="https://www.ibm.com/docs/en/wasdtfe?topic=annotations-annotating-ejb-bean-create-web-service" title="Opens a new window" onclick="javascript:helpWindow('https://www.ibm.com/docs/en/wasdtfe?topic=annotations-annotating-ejb-bean-create-web-service'); return false;"> Annotating an EJB bean to create a web service</a> for instructions on using WebSphere Application Server Developer Tools for Eclipse to make these code changes. After wrapping the EJB beans in web services, use the web service client to call the EJB web service. After testing, you can remove the EJB remote annotations or configuration. </p>
<h5>Handling Transaction Propagation</h5> Liberty provides Web Services Atomic Transaction (WS-AT) support which enables distributed global transactions. When your EJB are deployed as web services, WS-AT can be used to manage the transactions. See <a href="https://www.ibm.com/docs/en/was-liberty/base?topic=liberty-web-services-atomic-transaction-overview" title="Opens a new window" onclick="javascript:helpWindow('https://www.ibm.com/docs/en/was-liberty/base?topic=liberty-web-services-atomic-transaction-overview'); return false;"> Web Services Atomic Transaction overview</a> for more information.
<p> For more information on related topics, see </p>
<ul>
<li><a href="https://www.ibm.com/docs/en/was-liberty/nd?topic=liberty-using-enterprise-javabeans-remote-interfaces" title="Opens a new window" onclick="javascript:helpWindow('https://www.ibm.com/docs/en/was-liberty/nd?topic=liberty-using-enterprise-javabeans-remote-interfaces'); return false;"> Using enterprise JavaBeans with remote interfaces on Liberty</a></li>
<li><a href="https://www.ibm.com/docs/en/was-liberty/core?topic=deal-using-enterprise-javabeans-applications-that-call-local-ejb-components-in-another-application" title="Opens a new window" onclick="javascript:helpWindow('https://www.ibm.com/docs/en/was-liberty/core?topic=deal-using-enterprise-javabeans-applications-that-call-local-ejb-components-in-another-application'); return false;"> Using enterprise JavaBeans applications that call local EJB components in another application</a></li>
</ul>
</div>
<div class="Text"><p>This rule flags the use of any JAX-RPC specific packages and configuration files. Also, this rule will flag any use of the
<code>jaxrpc-mapping-file</code> tag in XML Mapping files. The following table lists Java packages, configuration files and
XML mapping files impacted by this rule:</p>
<h3>Packages</h3>
<ul>
<li>javax.xml.rpc</li>
<li>javax.xml.rpc.encoding</li>
<li>javax.xml.rpc.handler</li>
<li>javax.xml.rpc.handler.soap</li>
<li>javax.xml.rpc.holders</li>
<li>javax.xml.rpc.server</li>
<li>javax.xml.rpc.soap</li>
</ul>
<h3>Configuration Files</h3>
<ul>
<li>ibm-webservices-ext.xmi</li>
<li>ibm-webservices-bnd.xmi</li>
<li>ibm-webservicesclient-ext.xmi</li>
<li>ibm-webservicesclient-bnd.xmi</li>
<li>ws-security.xml</li>
</ul>
<h3>XML Mapping Files</h3>
<ul>
<li>webservices.xml</li>
<li>web.xml</li>
<li>ejb-jar.xml</li>
<li>ibm-webservicesclient-bnd.xmi</li>
<li>application.xml</li>
</ul>
<p>
The Java API for XML-based RPC (JAX-RPC) is not supported on Liberty or Liberty Core.
The technology is deprecated in WebSphere Application Server traditional V9.0 and might be removed in a later version.
If your application uses JAX-RPC, the preferred migration path is to use JAX-WS, but here are the alternatives:</p>
<ul>
<li>Option 1: Migrate JAX-RPC web services to JAX-WS web services</li>
<li>Option 2: Use the Apache Axis 1 JAX-RPC engine on Liberty</li>
<li>Option 3: Use WebSphere Application Server traditional with its native JAX-RPC engine</li>
</ul>
</div>
© 2015 - 2025 Weber Informatics LLC | Privacy Policy