Per the recommendation from here: WAS 8.5: java.lang.ClassCastException: org.apache.xerces.jaxp.SAXParserFactoryImpl incompatible with javax.xml.parsers.SAXParserFactory, I've looked through all the jars and cannot find xercesImpl-2.8.1.jar. I did remove crimson_1.1.1.jar from my project but that did not alter the error (java.lang.ClassCastException: org.apache.xerces.jaxp.SAXParserFactoryImpl incompatible with javax.xml.parsers.SAXParserFactory). I looked for the method in question (SAXParserFactoryImpl) and found it here: C:\Program Files\IBM\IBMIMShared\plugins\org.apache.xerces_2.9.0.v200805270400.jar. Since this jar is part of the Websphere installation, how can I remove it? Or does it need to be updated with a newer version that resolves this incompatibility?
Ok, I found the solution. With the goal of replacing crimson_1.1.1.jar, I looked for other jars (on my machine) having the class SAXParserFactoryimpl. I found it in several jars, two in particular: xercesimpl-2.8.0 and xercesimpl-2.9.1. I ultimately picked xercesimpl-2.8.0.jar because I needed to include another jar in my app, commons-fileupload-1.2.jar. When I downloaded this commons package to include it into my app, it came with xercesimpl-2.8.0.jar. So with that as the connection, I removed all references to crimson_1.1.1.jar and replaced it with xercesimpl-2.8.0.jar in my application. I also had to set my EAR's deployment descriptor (EAR > deployment descriptor > Deployment tab > Application section) to PARENT_FIRST for Classloader mode and APPLICATION for WAR classloader policy. So with the jars swapped and the deployment descriptor modified, the server started up w/o error and no longer got this incompatibility error and my application was finally working!
Related
I get this error in a Java maven project. The weird thing is, it doesn't appear on every machine so I assume it has something to do with a configuration issue.
The class RoleKeyCacheImpl is a #Startup #Singleton:
#Startup
#Singleton
public class RoleKeyCacheImpl implements RoleKeyCache { ... }
That's the error Wildfly triggers when deploying the service.
Caused by: java.lang.IllegalArgumentException: WFLYEE0040: A component
named 'RoleKeyCacheImpl' is already defined in this module at
org.jboss.as.ee.component.EEModuleDescription.addComponent(EEModuleDescription.java:167)
at
org.jboss.as.ejb3.deployment.processors.EJBComponentDescriptionFactory.addComponent(EJBComponentDescriptionFactory.java:58)
I've tried:
installing a new Wildfly (V10, V13) on the same machine -> doesn't help
installing a completely new Eclipse on this machine -> doesn't help
cleaning & rebuilding all related projects
making sure the deployments-folder is empty and doesn't contain old versions of the same WAR
read the related question here which also didn't help (they use Spring): A component named 'XXX' is already defined in this module in JBoss 7.1.1
read and tried this q&a: Wrong dependencies with EJB in JBoss Wildfly (server-clean) -> doesn't help
deleted and rebuilt the local maven rep (".m2") -> no effect
checking out the same source on another computer -> does work on one machine, on another it gives the same error
I have absolutely no clue what the issue is or even could be. On one machine, we check it out and it runs without errors. On others, the exact same error happens.
Does anybody have an idea?
I had this same issue multiple times with EAP 7.1 and now again with WildFly 21.0.0. I know by experience this is an issue caused by Eclipse who tries to deploy automatically to a configured WildFly instance. During the deployment (or undeployment) some concurrent file issue arises and files who should be removed, are still on the filesystem, causing this error that a component is already defined.
In fact it is not already defined, it is just WildFly that is confused because it finds in his temporary directories some old files which shouldn't be there and reference your exact same component.
Solution: remove in the WildFly standalone directory the content in the 'deployments' directory and the 'tmp' directory. Rest assured, all what is there is okay to remove safely. Reboot and the error message will be gone ;-)
You should pay attention to not have two #Stateless EJB annotations on top of two classes with the same name - in the same module.
You may differentiate them by using the name attribute in the annotation and put different values in each class
Looks like the class already exists. Check if it does...you may have to rewrite that part of EEModuleDescription to use its own private methods (which would be what you would write) rather than overriding methods in RoleKeyCacheImpl. If the class actually does not exist then right-click on the project -> Maven 2 Tools -> Generate Eclipse Artifacts (Check for Updates). That will regenerate all of the dependencies that the project uses. Also please be sure that you have not added any new projects to the classpath by mistake as that may also cause this error.
I just ran into this today when a colleague added a maven dependency.
Turns out this dependency was a jar with a nasty classpath entry or "../" in the manifest.
I edited the jar's manifest.mf that was cached in my local maven repository using 7-zip and removed the "../" classpath entry.
Then re-packaged my war file (maven clean install) and bingo, it works!
In my case it was caused by org.libreoffice jurt version 5.4.2 (but other versions I checked also have the classpath nastiness).
Unfortunately I was lucky we pinpointed it to a dependency, YMMV!
2 jars in WEB-INF/lib of Websphere 8.5.5.5 are having same directory structure
org.json.* .
json.jar Compiled withJDK 1.6
commonlib.jar compiled with JDK 1.7
Iam receiving below exception during the JVM startup in one environment while another environment has same jars and same classpath but there its working properly. WAS is running Java 1.6 due to which getting UnsupportedClassVersionError
6/23/16 15:59:32:091 CDT] 0000005e InjectionProc W CWNEN0047W: Resource annotations on the fields of the jmaki.xhp.XmlHttpProxyServlet class will be ignored. The annotations could not be obtained because of the exception : java.lang.UnsupportedClassVersionError: JVMCFRE003 bad major version; class=org/json/JSONObject, offset=6
When i specifically add the second jar to the class path of the second environment it gives the above error, otherwise it works properly Is it due to the classpath order?
class load: org.json.JSONException from: file:/hosting/configs/WebSphereD24/AppServer/installedApps/nodea/sear/swar/WEB-INF/lib/json.jar
class load: org.json.JSONObject$Null from: file:/hosting/configs/WebSphereD24/AppServer/installedApps/nodea/sear/swar/WEB-INF/lib/json.jar
How does WebSphere decide the jar to load the class=org/json/JSONException from . This class is present in both the jars... How come its loading from json.jar in one and common.jar in another.
The order of WEB-INF/lib JARs is unspecified, so the order will typically be defined by the file system. You should remove duplicate classes rather than trying to rely on any particular order.
[I originally posted this on the websphere forums bot didn't see a timely response. I'm re-posting here with slightly more content]
The Problem
I added a jar (call it "Foo.jar") to our enterprise application (i.e. ".ear"), created the manifest entry, etc., and found, to my surprise, that when my EJB instantiated FooClient, websphere threw a java.lang.LinkageError upon org.slf4j.LoggerFactory
I've added classloader debugging to the trace and did not find much. I was hoping to see "where WAS actually found the slf4j class". Here are the entries:
[9/24/14 16:23:01:417 CDT] 00000067 CompoundClass > loadClass org.slf4j.LoggerFactory this=com.ibm.ws.classloader.CompoundClassLoader#5c2687e4[app:yourappServer] Entry
[9/24/14 16:23:01:418 CDT] 00000067 CompoundClass < loadClass org.slf4j.LoggerFactory java.lang.LinkageError: org.slf4j.LoggerFactory Exit
I've checked my was8 directory and found various copies/versions of the slf4j jar.
/plugins
/osgiappbundles/com.ibm.ws.osgi.applications/aries/slf4j-api-1.5.6.jar
/slf4j-api-1.5.6.jar
/profiles/AppSrv01
/installedConnectors/activemq-rar-5.9.1.rar/slf4j-api-1.7.5.jar
/wstemp
/appdepl14769b0c2de/slf4j-api-1.7.5.jar3472682177251273594.tmp
/appdepl14769b0c2de/slf4j-api-1.7.5.jar7922145899030561292.tmp
Another developer told me "you won't be able to use Foo.jar" because we would need to put "Parent_last" and that's not an option for this project currently.
Additional Context
Websphere 8.0.0.7
RAD 9
Questions
java.lang.LinkageError : is this a 'classloader problem' or 'wrong version of class' problem? My experience with "wrong version of class" problems I usually see "NoSuchMethod" errors, not instantiation exceptions.
Any other way around this?
Updates
I read a bit about shared libraries and "isolated classloader" and this seemed the solution. However for some reason, my RAD/Eclipse UI seems broken as it does not 'save' when I associate the shared library with an application or module. It subsequently disappears.
thanks in advance
if you want to use newer library which is already there in websphere parent_last is the way to go
if not, remove the slf4j jar from the app, and use the version that is given by vendor
Check the version of SL4J expected by Foo.jar and the one you are using: they are surely different. Ensure the correct version has precedence in your classpath: you can put it in WEB-INF/lib but also check that you have just one version of it in WEB-INF/lib.
To discover which SL4J jar you are using you can run
java -verbose:class ....
and the JVM will dump out what it's loading, and from where.
You say "I usually see NoSuchMethod errors" instead of LinkageError; in this case the method exists but has some other incompatibility.
After application deployment in websphere application server v8,I'm getting the above error on JVM startup.MANIFEST.MF file contains two jars spring-2.5.5.jar & spring-sandbox.jar (version 1.2) and the said method "isPublicStaticFinal" is not present in spring-sandbox.jar but it's present in spring-2.5.5.jar (both having same package with same class i.e.org/springframework/util/ReflectionUtils) I guess there's something with version mismatch or conflict between two classes in the jars.I'm not able to get the latest version of sandbox jar.Also, I can't remove that jar as application is using some functions in that jar.Does entries/order of jars in classpath of MANAIFEST.MF matters? Any solution for this please?
Thanks Angelo.It is working fine now.
I have re-ordered the classpath enteries in Manifest.mf so that it loads first jar where the class and method is available.So, this is my conclusion now..order of jars matters in Manifest specially when two jars contains same class with same method and same package indeed.
I have problem with EAR module deployed in WAS6.
To support the MQ 7 features in my App. I follow the below steps:
Put Class loader policy as PARENT_LAST.
Placed all MQ 7 related jars in the root of EAR.
EAR contains Web module. When I try to start the application, I got following exception:
javax.servlet.jsp.JspException: Can't get definitions factory from context.
at org.apache.struts.taglib.tiles.InsertTag.processDefinitionName(InsertTag.java:575)
at org.apache.struts.taglib.tiles.InsertTag.createTagHandler(InsertTag.java:474)
at org.apache.struts.taglib.tiles.InsertTag.doStartTag(InsertTag.java:436)
at com.ibm._jsp._home._jspx_meth_tiles_insert_0(_home.java:106)
at com.ibm._jsp._home._jspService(_home.java:81)
The War contains the following jars.
xstream-1.3.1.jar,xercesImpl.jar, xalan.jar,struts.jar, standard.jar,commons-validator.jar, commons-net-1.4.0.jar, commons-fileupload.jar, commons-digester.jar, commons-collections.jar, commons-beanutils.jar,resolver.jar,jstl.jar, jfreechart-1.0.2.jar, jcommon-1.0.5.jar, jaxen-full.jar, jakarta-oro.jar.
EAR contains the following Jars,
com.ibm.mqjms.jar, com.ibm.mq.jmqi.jar, com.ibm.mq.jar, com.ibm.mq.headers.jar, com.ibm.mq.commonservices.jar,log4j.jar,dhbcore.jar.
And I set the class-path attribute in my Manifest file of the WAR with log4j.jar
Please anyone suggest me how Websphere's classloading policy works for where I went wrong.
Karthik
Some time ago I did something similiar. I wanted to use a specific version of a library which was already used within the WebSphere Application Server. That is the reason why you have to put your libraries in the EAR file and set the application server to PARENT_LAST class loader order.
Correct me if I am wrong, but you also have to specify your custom MQ client libraries in Manifest of your WAR file. You only mentioned Log4J. It should look somehting like this:
Class-Path: com.ibm.mqjms.jar com.ibm.mq.jmqi.jar [...] log4j.jar
Anyway, you can always check what libraries are in the Classpath of you application if you log into the Integrated Solutions Console (aka Admin Console) and check the Troubleshooting section. There is a classloader viewer. Just click yourself through the tree and check which library path are mentioned and which you would expect.
Finally, as Dylan already mentioned in his comment: WebSphere Application Server version 6.1 runs out of support September 30, 2012. :)