Kerry Ward

Greenhorn
+ Follow
since Nov 19, 2008
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Kerry Ward

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.
15 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:

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.
15 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.

See:
http://www.ibm.com/developerworks/forums/thread.jspa?threadID=103117
https://coderanch.com/t/77967/Websphere/WSAD-JDOM

I have added the following jars to the root of my ear:
jaxen.jar jdom.jar saxpath.jar xalan.jar xercesI
mpl.jar xmlsec.jar

I exported the ear and in my wars META-INF/Manifest.MF I have:
Class-Path: jaxen.jar jdom.jar saxpath.jar xalan.jar xercesImpl.jar xmlsec.jar

In the application descriptor of the ear it sets the class loader to be parent_last for both the ear and the wars.

Tried it with war classloader policy as both application and module
15 years ago
I am having a problem with getting jdom 1.1 to load from a servlet. Here is the error I get.

java.lang.VerifyError: (class: com/signer/notification/NotificationProcessor, method: createTestEnactCMSResponse signature: (Ljava/lang/String Lorg/jdom/Document Incompatible argument to method

I am running under WebSphere 5.1, and developing using RAD 6.0.1

I have an ear with EJB and Wars.

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.

I read the following link - http://www.technicalfacilitation.com/get.php?link=classloading - and believe I have set in place the proper steps.

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.

Any assistance with this is greatly appreciated.
15 years ago