I am porting an old IBM Process Server application to IBM WebSphere Liberty. It contains a lot of code based on Service Data Objects (SDO). I have some good working code, running as standalone Java, using JDK8. I am using eclipselink 2.7.7, specifically 2 jar files;
eclipselink.jar
commonj.sdo_2.1.1v20111051852.jar
I have built this code into a Servlet to handle SOAP requests, and packaged it, along with other code, into an EAR file, which I deployed under IBM WebSphere Liberty 20. It doesn't work. There seems to be a clash with the Liberty version of EclipseLink.
If I deploy the code as a WAR file, and add a classloader of "PARENT_LAST", the code works fine.
However, if I try to deploy the code in an EAR file, and set a classloader of "PARENT_LAST" for the ear file, I get this error;
[ERROR ] CWWKZ0106E: Could not start web application S21.
[ERROR ] CWWKZ0002E: An exception occurred while starting the application S21. The exception message was: com.ibm.ws.container.service.state.StateChangeException: java.lang.LinkageError: loader constraint violation in interface itable initialization: when resolving method "org.eclipse.persistence.jpa.PersistenceProvider.getProviderUtil()Ljavax/persistence/spi/ProviderUtil;" the class loader (instance of com/ibm/ws/classloading/internal/ParentLastClassLoader) of the current class, org/eclipse/persistence/jpa/PersistenceProvider, and the class loader (instance of org/eclipse/osgi/internal/loader/EquinoxClassLoader) for interface javax/persistence/spi/PersistenceProvider have different Class objects for the type javax/persistence/spi/ProviderUtil used in the signature
Does anyone know whether I can replace the IBM Liberty implementation of EclipseLink with my version 2.7.7 version?
My application also uses JPA, which is working fine under Liberty, so I don't want to break that.
Any help / guidance appreciated... it's been a very long saturday.
PS:
I tried running the java code using only the SDO library (commonj.sdo_2.1.1v20111051852.jar), and relying on the WebSphere Liberty runtime jars to provide Eclipselink functionality, and I got the following errors, which is why I then moved to adding the "matching pair" of Eclipselink / SDO jars mentioned above;
Caught Exception : org.eclipse.persistence.internal.security.PrivilegedAccessHelper.getSystemPropertyBoolean(Ljava/lang/String;Z)Z
java.lang.NoSuchMethodError: org.eclipse.persistence.internal.security.PrivilegedAccessHelper.getSystemPropertyBoolean(Ljava/lang/String;Z)Z
at org.eclipse.persistence.sdo.helper.SDOHelperContext.<init>(SDOHelperContext.java:93)
at org.eclipse.persistence.sdo.helper.SDOHelperContext$DefaultHelperContextResolver.getHelperContext(SDOHelperContext.java:1432)
at org.eclipse.persistence.sdo.helper.SDOHelperContext.getHelperContext(SDOHelperContext.java:492)
at org.eclipse.persistence.sdo.helper.SDOHelperContext.getHelperContext(SDOHelperContext.java:471)
at org.eclipse.persistence.sdo.helper.SDOHelperContext.getHelperContext(SDOHelperContext.java:456)
at org.eclipse.persistence.sdo.helper.delegates.SDOXMLHelperDelegator.getXMLHelperDelegate(SDOXMLHelperDelegator.java:178)
at org.eclipse.persistence.sdo.helper.delegates.SDOXMLHelperDelegator.load(SDOXMLHelperDelegator.java:78)
at com.ebs.solas2021.port.adapter.ui.SOAPRequestHandler.main(SOAPRequestHandler.java:237)
It's amazing what you find whgen you re-read the documentation in the cold light of a new day. It turns out that it's possible to install a JPA 2.2 Container on Liberty, while supplying one's own implementation of EclipseLink. Works like a charm.
Documented here: https://openliberty.io/blog/2018/06/29/full_java_ee_8_liberty_18002.html
Related
I have a web application that used to run fine on many web servers (tomcat, jboss, weblogic and websphere). Now, however, it has an error when deploying on WebSphere 9.
The app contains the jar javax.transaction-api-1.2. Some of its classes, e.g., javax.transaction.xa.XAResource, are also included in Java SE, but not all of them. Some are specific to Java EE and are required by some 3rd-party libraries in my app. The app is always deploying with child-first (parent-last) classloader.
WebSphere 9 throws this error during startup when the app tries to load the Oracle JDBC driver:
java.lang.LinkageError: loading constraint violation: loader "com/ibm/ws/classloader/CompoundClassLoader#7157be44" previously initiated loading for a different type with name
"javax/transaction/xa/XAResource" defined by loader "com/ibm/oti/vm/BootstrapClassLoader#422c7b1b"
Note that we aren't actually using XA transactions in the app, we are using regular transactions.
On other servers, and previous versions of WebSphere, it was never a problem. The server didn't care that we load XAResource from inside the war, even if it was previously loaded somewhere in the server. Now WebSphere 9 is different, it says that the app classloader already loaded this class from the server, but I don't know why or when did this happen.
Any idea how to solve this?
Remove the transaction API from your application. JTA 1.2 is already included in the server and provides no value in your applications. It's always risky to bring Java EE/SE APIs in a parent-last class loader unless you are 100% certain that they are technically necessary, because they can lead to issues like this one.
I can't say how this worked in previous server versions (there have been some Java-level changes in enforcing linkage issues like this), but the solution is reasonably straightforward.
At the end we did two things to solve this problem.
1) We upgraded the jta jar to version 1.3 (link here). This jar solves the problem by avoiding duplicate classes - it contains only J2EE classes and omits the J2SE classes that are already included in the JVM.
2) We upgraded WebSphere server from 9.0.0.7 to 9.0.0.11.
At the time, I suspected just upgrading the jar should suffice, but our QA had some issues with it and they also upgraded the server. Due to lack of time, we didn't investigate it further and just decided to do both.
When I am trying to deploy my war file from tomcat to websphere I am getting the following error.
1)org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [org.apache.cxf.bus.spring.SpringBus]: Constructor threw exception; nested exception is org.apache.cxf.bus.extension.ExtensionException: Could not load extension class org.apache.cxf.ws.policy.AssertionBuilderRegistryImpl.
2)org.apache.cxf.bus.extension.ExtensionException: Could not load extension class org.apache.cxf.ws.policy.AssertionBuilderRegistryImpl.
3)java.lang.IncompatibleClassChangeError: org.apache.neethi.AssertionBuilderFactory
I tried by changing the class loader from parent first to parent last(Vice-Versa).But still I am getting same error
Help me out.
There are potentially several issues with your app:
You probably include Java EE jars in your application - like jee.jar, servlet.jar etc - please remove all these jars from WEB-INF/lib directory.
It looks like you are bundling your own web services engine (CXF) inside your application. tWAS provides its own web services engine. So you either need to migrate to the provided or disable tWAS one. Check the Using a third-party JAX-WS web services engine page. You will need to set DisableIBMJAXWSEngine property and configure module classloader for your war to parent last.
I still would recommend migrating to Liberty if possible, instead of traditional.
I'm working to migrate an application from Oracle Application Server to JBoss EAP 6.1. I have most things working but I am getting one error that I haven't been able to figure out:
13:27:29,743 ERROR [com.myproj.db.dao.myDao] (Thread-164) Get Prepared Statement:
java.lang.ClassCastException:
org.jboss.jca.adapters.jdbc.jdk6.WrappedPreparedStatementJDK6 cannot be cast
to oracle.jdbc.internal.OraclePreparedStatement
I have Oracle set up as a module in JBoss for connection pooling using ojdbc6.jar (and it works for other parts of the application), but for the one part of the application that uses an OraclePreparedStatement, it gets the error.
I did make certain that there is no ojdbc6.jar file in the WAR file. The only one in JBoss seems to be inside of the module.
I did try changing the OraclePreparedStatement class to oracle.jdbc.OraclePreparedStatement, but the results are the same.
I did try running with TRACE on for logging to see where classes were loading from. OraclePreparedStatement was loaded from the module with the exception of this line:
4:31:40,583 TRACE [org.jboss.modules] (Thread-84) Finding class
oracle.jdbc.OraclePreparedStatement from Module "deployment.myProj.war:main" from
Service Module Loader
Here's a link to an excerpt of the log - basically just the lines related to OraclePreparedStatement.
I have confirmed that there is no ojdbc6.jar (or any Oracle related jars) in the WAR file, and there is no OraclePreparedStatement class inside of the WAR file either.
I do have the module listed as a dependency in my JBoss deployment structure xml file.
Anyone have any ideas?
From looking at the javadoc I would guess that org.jboss.jca.adapters.jdbc.jdk6.WrappedPreparedStatementJDK6 is wrapping the underlying Oracle JDBC driver.
org.jboss.jca.adapters.jdbc.jdk6.WrappedPreparedStatementJDK6 has a method to get the underlying statement. Perhaps you should try something like the following:
WrappedPreparedStatementJDK6 statement = ...
OraclePreparedStatement oracleStatement = (OraclePreparedStatement)statement.getUnderlyingStatement();
I am trying to get an apache camel app using CXF working on WebSphere.
Noticed a number of errors
Caused by: java.lang.IncompatibleClassChangeError: org.apache.neethi.AssertionBuilderFactory
at java.lang.ClassLoader.defineClassImpl(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:262)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:69)
This occurs because the org.apache.neethi classes are loaded from the WAS run-time instead of the neeti3.0.2.jar from WEB-INF/lib
here is the info from class loader:
class load: org.apache.neethi.builders.AssertionBuilder from: file:/D:/Tools/WebSphere/AppServer/plugins/org.apache.axis2.jar
The Web Application config has been changed to use the class loader policy. It is set to Parent Last. Yet this class seems to be using the Parent First Policy.
Is there anything in the CXF package that over-rides this policy?
I noticed that using Axis2 and WAS
http://axis.apache.org/axis2/java/core/docs/app_server.html
Avoiding conflicts with WebSphere's JAX-WS runtime has some additional steps mentioned for Axis2. Is there something similar that is required to get this to work?
Thanks
Manglu
Not specific to Camel, but we are dealing with a similar issue.
1) You can use an isolated shared library if you want. This seems to fix the classloader from pulling in these other libraries via OSGi. This solution isn't for everyone.
2) When setting an app that PARENT_LAST, make sure you're doing it in the correct place. If you have jars inside your wars, then you'll have to set PARENT_LAST on the WAR modules, not the application. In the WAS console> Applications > Application Type > websphere enterprise applications> MyEAR > manage Modules > MyWar > Change the "Class loader order" and make it "parent last"
3) After you make your changes, you can export the ear file. In the ear, there is a file META-INF/ibmconfig/cells/defaultCell/applications/defaultApp/deployments/defaultApp/deployment.xml that has this config. For maven ear's, you can put this into src/main/application for it to be packaged up with the ear.
Hope that this helps. Good luck.
We are discussing a similar topic at the Camel mailing lists. I suggest to take a look there: http://camel.465427.n5.nabble.com/camel-cxf-in-WebSphere-without-geronimo-jetty-depdendencies-possible-tp5726490.html
I am trying to write a JAX WS client for a service exposed using Axis2, WebSphere8, Java 1.6.
Standalone client(i.e. client running in my local machine) works fine but when I deploy the client in a application running in same websphere server I get
java.lang.ClassCastException: Cannot cast class org.apache.axis2.jaxws.spi.Provider to class javax.xml.ws.spi.Provider
at line OpenPortType service = OpenService
.create(wsdlFile.toURL(),
new QName( "http://www.test.com/schemas/public/open-api/Open/","OpenService")).getPort(
OpenPortType.class);
When I tried to google I found similar problem existed in weblogic : https://wso2.org/jira/browse/CARBON-4835
When we see source of axis2.jaxws.spi.Provider class we come to know that it's a subclass of javax.xml.ws.spi.Provider !!
I'm wondering what could be wrong ? Any idea ?
Unless you are calling Axis2 capabilities directly, rather than simply using JAX-WS APIs, you do not want to package Axis into your EAR. WebSphere does provide its own JAX-WS implementation which I'm not surprised conflicts with another JAX-WS implementation you've deployed in your app. (In particular, note that WebSphere's own implementation is based on Axis2.)
If you do need to deploy a different implementation, you'll probably have to at least adjust your WebSphere classloader policy to parent_last. There might be more to do as well; it's been a while since we did this ourselves. But it's much easier and cleaner to use the built-in JAX-WS implementation, which means not deploying any of those jars at all.