• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

Jdom Servlet Classloading Error

 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Sheriff
Posts: 28370
99
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Kerry Ward
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Paul Clapham
Sheriff
Posts: 28370
99
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Kerry Ward
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Paul Clapham
Sheriff
Posts: 28370
99
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Kerry Ward
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Look! It's Leonardo da Vinci! And he brought a tiny ad!
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic