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:
Manifest-Version: 1.0
Class-Path: jdom.jar
eflex-ncar.jar
Here is the doGet method of ViewServlet
Here is the TestJDom testit method:
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.
Thanks.