I think you were on the right track. But just because you have xerces and xalan in the WEB-INF/lib directory doesn't mean log4j.jar will find it there. If the log4j.jar is placed in the "lib/app" directory as you described, it will not be loaded by the module classloader. Instead the Application Extension classloader will load it. That must in turn find xalan and xerces. It can not refer that to the module classloader. It can only refer class loading up to the WebSphere classloader (ws.ext.dirs) or the Java classloader (global classpath). Placing updated jars in your module should have no impact as you observed. You must either promote the latest xerces and xalan jars to the "lib/app" or demote the log4j.jar into your module.
Craig >>> [EMAIL PROTECTED] 09/04/02 09:06AM >>> Hi, I've developed a servlet-based application that is running on WebSphere 4.01 (on AIX) and is doing some XSL-transformations on XML-files using Xalan and Xerces. Since I switched logging to Log4J we experience some strange problems concerning the XSL-scripts, i.e. scripts that were working fine before (except for some warnings because of variables being used without prior declaration) now produce fatal errors. Of course it's easy to just fix the scripts (i.e. declare the variables) and we'll certainly do this, but what really concerns me is, that there seems to be a dependency between Log4J and Xalan/Xerces. However I don't have any clue why, because all relevant classes seem to be in different packages and therefor shouldn't interfere. The problem appears with different versions of Xalan and Xerces, though primarily we use Xalan 2.0.0 and Xerces 1.2.1 (the versions that are contained in WebSphere 4.01). I put the log4j.jar (version 1.2.3) in the WebSphere's "lib/app" directory and tried with and without putting Xalan and Xerces into the "WEB-INF/lib" directory of my application (because I thought it might be depending on the order in which the classes are loaded and classes in "WEB-INF/lib" should be loaded before those in "lib/app" and these again before those in "lib", where the Xalan and Xerces WebSphere is using reside), but it doesn't make any difference. Does anybody have any idea what might be the reason for this problem and how I can solve this without switching back to my own logging classes (as I already mentioned above, just fixing the scripts is not enought, because we cannot tolerate a dependency between Log4J and Xalan/Xerces)? I suppose that somehow the Xalan/Xerces classes get access to some of the Log4J XML/XSL-related classes. These classes are newer than the classes contained in the Xalan/Xerces versions that we're using and therefor more strict, which is why they not only warn when a variable in the XSL is used without prior declaration but throw an exception and stop further processing. But I don't have any idea why this happens and how I can avoid this. Any help is greatly appreciated. Regards, Markus. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> **************************************************************** Please Note The information in this E-mail message is legally privileged and confidential information intended only for the use of the individual(s) named above. If you, the reader of this message, are not the intended recipient, you are hereby notified that you should not further disseminate, distribute, or forward this E-mail message. If you have received this E-mail in error, please notify the sender. Thank you ***************************************************************** -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
