Categories
Articles

IBM Websphere – Worst NiGhTmArE (NoClassDefFoundError – com.sun.org.apache.xerces.internal.dom.DocumentImpl)

Last week, I was trying to deploy CXF 2.X webservice application on Websphere 6.1.0.X. Everything worked well and no error at the time of deployment. But while invoking webservices, we were getting an error

java.lang.NoClassDefFoundError: com.sun.org.apache.xerces.internal.dom.DocumentImpl

After googling, we found that this class is integral to JDK 1.5 and ships along with it. We were bit confused as the application was working fine on development machines with no errors. After googling more, the same problem was reported on most of the forums by Websphere users.

Well there was definitely difference between the development environment and testing environment. Developers were using Sun JDK 1.5.0_16 + Jboss 4.2.2 GA, while the testing environment had IBM JDK 1.5 SR 2 + IBM Websphere 6.1.0.25.

The class mentioned above is already available in rt.jar of SUN JRE but it is missing from IBM JDK (what a X@#$). The solution to this problem is to download JAXP library from https://jaxp.dev.java.net/. It is downloadable as .class file. To get the jar files from the class, you need to execute the .class file using “java” command. It will extract JAR files, copy xercesImpl.jar file to WEB-INF/lib folder of the application & restart the server.

If the application still gives the same error, make sure the classloader policy is changed to load application classes first.

By Carbon Rider

Hi this is Yogesh, welcome to my world. Being passionate about learning new technologies and building frameworks, I end up spending most of my time in front of computer. But over last few months, I realised apart from being good coder and designer (Yes I am) I have something hidden in me. And thats called ART.

6 replies on “IBM Websphere – Worst NiGhTmArE (NoClassDefFoundError – com.sun.org.apache.xerces.internal.dom.DocumentImpl)”

I havent tried that option but I think changing class loader priority should ideally have no impact on the problem listed here. The error clearly says that it is not able to locate the class. If it was not able to locate the class in the given application, it should have tried to search in the ibm jars. Before making the changes the class locator facility was not able to locate this class even in IBM jars.

Hi Yogesh,
hope u remember me; there are a few things that i would like to share here :
1. as an ideal practice, the dev and prod configs should always be the same , unfortunately , we used 2 different app servers all together.
2. does the java 1.5 spec say that xerces parser should be shipped in the JRE (i dont know this , i am asking you), but one thing i know is that IBM has their own implementation of JRE , and they are free to not bundle anything which they feel is not important or they have made their own implementation for it.

Hi Hardeep,

You are right, both development and production environment configuration should match. But due to licensing & resource issues most prefer to have opensource/freeware servers on development environment. (I feel thats where the actual problem starts, people dont even prefer to have one environment which can simulate production and are interested in spending countless hours in resolving environment problems.)
Also there is no mandate on shipping a specific JAR whenever one wants to develop his own JVM implementation. Above problem cannot be attributed to either websphere and not even to CXF, though CXF makes hardwired reference to SUN’s implementation. They may be interested in assuring that the results may not vary from one environment to another. (Everyone follows JSR, still you may notice some variations when a program is executed on hetrogeneous environments – specially when an XML parser is instantiated depending upon the platform settings).

This article really helps. I copied jaxp-api.jar and jaxp-ri.jar from JAXP library to WEB-INF/lib folder, and it solved the problem. Thank you so much 🙂

Leave a Reply