Does the classloading hierarchy ever cause problems?
Now, while your basking in the glow of the effectiveness of the Java classloading hierarchy, think about this alternative scenario:
Perhaps one of your developers has gone hog wild, XML crazy, and has been using the latest, greatest version of the Xerces XML parser in all of their web applications. The developer correctly packages the files required to implement the XML parser in the lib directory of the war, right alongside all of the Servlets and helper classes that need to use the xerces parser. WebSphere shouldn’t have any problem finding these Xerces-XML parser files, right?
Well, the developer may have configured everything to work ‘honkie dorie’ in the development tool, but as soon as the application goes into production, all sorts of errors will be generated about deprecated methods, classes not conforming, or even that certain methods being invoked don’t actually exist.
This is where things get interesting. J
The IBM implementation of the WebSphere Application Server relies on a boatload of JAR files and Java files, many of which come from common, open source projects such as xerces, xalan and ant.
If you check out the ‘lib’ directory of the application server, which is the directory the WebSphere extensions classloader pulls classes from, you’ll discover a plethora of JAR files and Java classes that just might conflict with your attempt to use the latest and greatest technologies on the open market.
In this particular scenario, the WebSphere extensions classloader is picking up its own, older version of the xerces.jar file. None of the calls the developers are making to the latest xerces implementation are working properly, despite having placed the latest xerces.jar file right there in the lib directory of the web module. The older xerces.jar file in the lib directory of the application server trumps any xerces.jar file found below it on the classpath hierarchy.
ref: http://www.technicalfacilitation.com/get.php?link=classloading
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment