Hi we use websphere in my company
The websphere installation has two ears ear1 and ear2
We have a policy of a singleclassloader
When set to singleclassloader we get a class not found exception from ear2
spring-oxm3.1.0.RELEASE.jar
org.springframework.oxm.MarshallingFailureException class not found
But by enabling "multiple classloaders" the problem goes away.
Why would the company have a policy of enforcing "single classloader" ?
Is the classnotfound exception caused because a class is defined a jar in both
ear1 and ear2?
eg ear1:jar1 and ear2:spring-oxm3.1.0.RELEASE.jar
And X is loaded from ear1:jar1 and thereby is spring-oxm3.1.0.RELEASE.jar is not loaded ? And when the request runs it fails and complains that MarshallingFailureException is not found?
Would that explain why the class is not found?
So is the solution to find what is the jar in ear1 that is causing spring-oxm3.1.0.Release.jar not to load? And remove it?
Could it be xerces or jaxb?
(We're running java version 1.5)
Thanks in advance.
In that old version of Java, all XML-related jars had many problems.
Your error details will tell you why the class is not being loaded. Most likely, it is a class with the same package/name but in a different jar
Company policies have to do with all the factors involved - development, maintenance, dependency management, and so on.
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.
I'm hitting the same problem described in here, but I don't know my websphere version at the time
More questions
1) does Removing commons-logging-1.1.jar fix it?
2) what if I really need to put commons-logging-1.1.jar in my application? How can I fix this?
Theres a fix pack of ibm for this.
https://www-304.ibm.com/support/docview.wss?uid=swg21502693
This happens because the class org.apache.commons.logging.impl.Jdk14Logger is loaded by a different classloader than the one that loaded the Log interface.
According to IBM's documentation, whenever you use a third-party library that WebSphere itself uses for its own internal purposes, you must:
Set your EAR's classloader policy to PARENT_LAST; and
Ensure that your EAR is self-sufficient. That is, that your third-party libraries (and their dependencies) are bundled within the EAR.
In your case:
Set your EAR's classloader policy to PARENT_LAST
Include commons-logging-1.1.jar within your EAR (you can place it in the "EAR Library" directory, usually EAR/lib).
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 wanted to implement an EJB client for JBoss 7.1 following this tutorial
http://middlewaremagic.com/jboss/?p=1177#comments which is based on the JBoss tutorial:
https://docs.jboss.org/author/display/AS71/EJB+invocations+from+a+remote+client+using+JNDI
I already tried the troubleshooting tips there, but still I get an exception:
javax.naming.NoInitialContextException: Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file: java.naming.factory.initial
Did anyone else encounter this type of problem and knows which jars (or better Maven dependencies) are needed on the classpath?
Best regards,
Helge
Have you referred to the ejb-remote quick start ? https://github.com/jboss-jdf/jboss-as-quickstart/tree/master/ejb-remote
That quick start contains the two Maven projects that are referenced in the jboss.org doc and have all the required dependencies.
I am currently working on a portlet that is using the commons-collections jar file and am getting a NoSuchMethodError. To resolve this issue I need to change the classloader of my WAR file from PARENT_FIRST to PARENT_LAST (in the application.xml file).
However, when I do this my portlet will not launch and when I log into the console it displays the message "The portlet is temporarily disabled". If I change the classloader back to PARENT_FIRST then it will launch again but then I get the NoSuchMethodError.
Does anybody have any suggestions on how to fix this issue ?
I am not sure how, but today I started getting error messages in the logs when I was getting "The portlet is temporarily disabled". I was getting a java.lang.LinkageError which was down to the fact that I had the servlet-api-2.5.jar and a jaxb jar which was conflicting with webshpere j2ee.jar. Once I removed these dependencies and set the classloader to PARENT_LAST, it seems to work properly. It seems that a lot of people face similar issues. The link below is also useful http://forum.springsource.org/showthread.php?33663-dispatcher-servlet-quot-not-a-servlet-class-quot-in-websphere
#MTH,
please try adding commons-collections as a shared library. See here for an example on how others have used shared library support [1]. That will give you the steps, just do it for the jars that you need to override/replace from WAS's classloader
[1] http://portals.apache.org/jetspeed-2/deployguide/deploying-jetspeed-to-websphere.html#section_4_2
thanks,
dims
You haven't provided any logs... but still, one of the most important things to look out for when setting your application to run PARENT_LAST is that your application isn't bundled with any system-level classes that may conflict with the ones provided by WebSphere Portal. For example, classes that pertain to the Portlet specification or the JavaEE specification.