Since I am using a later version of jdom, xerces, jaxen,... than what runs under WebSphere, I believe my problem is a classloading problem.
I have read a number of postings regarding this issue and they all seem to point the same way - replace the jars in WebSphere's application lib, or bundle the jars in the ear and change the class loader to parent_last. Can't do the first and the second just doesn't seem to be working.
I have added jdom and the other jars at the root of the ear file and have set the classloader mode to parent_last for both the ear and the wars. I have also tried setting the war classloader policy to both module and application to no avail.
Since the servlet seemed to be getting the old jdom, I also added the jars to the WEB-INF/lib folder of the wars and the META-INF/Manifest.MF of the wars shows a dependancy on the added jars. All to no avail.
I need to deliver to the customer a single ear file, and cannot replace the files that WebSphere uses - which I think is bad anyway.
One thing I did try that looks suspicious is I added a META-INF/Manifest.MF in the ears META-INF folder - and referenced the jars under the Class-Path. However, when I open this with the Jar Dependancy Editor there is a warning that the file is not associated with a project.
Your diagnosis looks right to me. But it appears to be based on the idea that Websphere includes JDOM in its part of the classpath when it runs web applications.
I ran the "snoop" servlet in my Websphere installation and didn't see JDOM anywhere in the classpath it showed me. But my Websphere is 6.1, and I guess there's also the possibility that IBM renamed the jar so its name doesn't include the letters "jdom" or incorporated it in some other way.
Anyway, are you sure that your version of Websphere includes JDOM? It's possible the problem is actually caused by something else.
posted 9 years ago
Quite certain. Found it in C:\Program Files\IBM\Rational\SDP\6.0\runtimes\base_v51\lib\jdom.jar
Also found other postings with classloader issues that have said they got it working using parent_last loading.
Okay. So let's run through all the things that might work but are probably not palatable:
1. Use the same version of JDOM that Websphere is using. Don't include it in your EAR but let Websphere's version be used.
2. Upgrade to Websphere 6.1. (From what I can see it doesn't include JDOM, but I didn't search the runtime's lib library, I just checked my web application's classpath.)
So anyway, it looks like there's an org.jdom.Document that's being passed to that method that isn't the version the method expects. Who is creating that object? And what about the NotificationProcessor class? Is that part of your application or part of Websphere? If it's the latter, then it will have been compiled against Websphere's version of JDOM so you want to let Websphere create the JDOM Document object as well.
I have no idea whether putting a manifest into your EAR file makes any difference at all.
posted 9 years ago
In response to the last post - unpalatable options: 1) Same version as websphere - Could take code base back to work with this, but my understanding is WebSphere's version is beta 7, which had big problems with large XML. Memory issues, performance goes out the window. 2) Use WebSphere 6.1 - customer not giving me this option.
So still trying to get the classloading working - assuming this is the problem. NotificationProcessor is a class my servlet code calls to process servlet requests. It has a method that passes a JDom Document as a parameter.
I started over with a test ear with just the basics, so I could limit the variables.
Here is the what my ear now contains
test.ear jdom.jar (utility jar - version 1.1) eflex-ncar.jar (project utility jar I have created) com.eflex.ncar.ViewServlet.class (extends HttpServlet with simple doGet method com.eflex.ncar.TestJDom.class (includes method to exercise JDom by creating elements). test.war (maps servlet to the class com.eflex.ncar.ViewServlet)
The MANIFEST.MF file of the war contains the following:
Here is the error I get with this. java.lang.VerifyError: (class: com/eflex/ncar/TestJDom, method: testit signature: ()V) Incompatible argument to method at com.eflex.ncar.ViewServlet.doGet(ViewServlet.java:34)
If I comment out the line - in the testit method, the error goes away. The method signature for Element addContent differs for JDom beta 7 and 1.1
I have both the test.ear and test.war web module set to be Parent_Last class loading. The WebSphere 5.1 server has the application class loader policy set to Multiple
These are my conclusions: 1) The web module class loader is finding the classes in eflex-ncar.jar since it is in the root of the ear and the MANIFEST.MF references it. 2) Since jdom.jar is also in the root of the ear and is referenced the same way in the MANIFEST.MF, the web module class loader should find the classes in this jdom.jar, provided the classes are not loaded by some other class loader. 3) Since the application class loader policy is set to Multiple, and the ear and war web module are set to Parent_Last, the web module's classloader should load the ear's jdom.jar classes first, and not reach WebSphere's classloader. 4) The error says that the Element class from jdom is being loaded by WebSphere's application class loader rather than the web module 5) Conclusion 4 is at odds with the other conclusions, so I am missing something, or my installation of WebSphere 5.1 is not working as advertised.
I think my next step is to temporarly replace the jdom.jar in websphere's lib directory and just see what happens. Any other suggestions are welcome. I can provide my test.ear if anyone wishes to delve into this.
Yes, I would agree with everything you wrote there. I just had a thought -- seems to me that Websphere has a classloader trace which you can turn on. I had to use it a couple of years ago when my ResourceBundles weren't acting right. If I recall correctly (p < 100%) it's in one of the tiny twisty corners of the admin application.
posted 9 years ago
For informational purposes - here is what I did to get around this problem.
First, I never did get Parent_Last to work in the Windows RAD environment. However, the same ear, using Parent_Last and Application class loading, did work in ZOS - which is the production environment. So to get my Windows RAD to work for development purposes, I deleted the jdom.jar out of the WebSphere 5.1 lib folder, and then my app works fine. Seems to have had no detrimental effect on WebSphere. I have seen postings that say WebSphere does not really use jdom, just included it for application developers.