I am experiencing wide application problems with how the classloader works in Tomcat. Using Tomcat v3.0.1 (something like that) JDK v1.2.2 Sun OS Please respond back to my JPMorgan account. Here is some history. I built several servlet based applications on the Java WebServer - but management asked me to move them into one architecture and choose Tomcat. So I began to move them, however they wanted one server, to use on process - with all my applications under one house ... We began by implementing a CVS repository and I used Ant to make by builds. But when I began to install the applications the server got crazy. So what happened? The classloader seems to be getting things wrong. First the Lotus XSL implementation from IBM does not work right with Jakata. The Sax classes in Jakata seem to not be correct with lotusxsl v1.0.1 - I tried the previous v0.2.0 - but that failed too. I have custom XSLT applications which are server side and parse XML using XSLT, and the XSL has custom Name Space programs in the XSL - which help in parsing. When I run them they fail. If I load the classes in front of the main libraries that Jakata uses - it works. Can someone please address this issue. See in the Java WebServer - it has no notion of Sax (it was before Sax - atleast the one I am using is) - so it works fine. But Jakata chokes. The next problem is how the classloader works when having my API run in the global lib, and having it try to access properties in my application level class path. I use WebMacro to build my servlets. When I load the WebMacro libraries in the global lib (via mod'ing the start script 'tomcat.sh') it fails. The problem is WebMacro is looking from its properties in the global classpath and not in the application classpath. This is a serious error in the server itself. It should look in its local path first, then to global. In this case it looks in global since the API is in global, and never even looks in application level classpath. Here is another problem with the classloader. If I have TopLink API in the global lib, and it tries to map the SQL rows to the objects which are in my application lib classpath, it chokes. TopLink can not access the classes in the application level classpath. This is a serious error. I am trying to build large scale applications in Jakata - but the way it works prevents this. I believe that you must be using the security mechanism in the Java VM which is preventing the global API to access the application level API (in the case of TopLink) above. Here is the TopLink output. I have confirmed that TopLink is connecting to the database (in my case IBM UDB v7.1) and is calling the SQL fine. EXCEPTION [TOPLINK-1011] (v2.5.1 GA May 11 2000): TOPLink.Tools.BuilderReader.BuilderException EXCEPTION DESCRIPTION: Could not convert: com.jpmorgan.ams.jxmlive.model.MessageAuditHolder into an accessible Java class. INTERNAL EXCEPTION: EXCEPTION [TOPLINK-3001] (v2.5.1 GA May 11 2000): TOPLink.Public.Exceptions.ConversionException EXCEPTION DESCRIPTION: The object, 'com.jpmorgan.ams.jxmlive.model.MessageAuditHolder' of class, 'class java.lang.String' could not be converted to 'class java.lang.Class', INTERNAL EXCEPTION: java.lang.ClassNotFoundException: com.jpmorgan.ams.jxmlive.model.MessageAuditHolder Later this weekend I am going to run the application in JProbe to profile the application and try to trace it. Can someone give me a clue on how to get around these problems? Is there some security properties that I can set to allow global API to make calls into application level classes? What am I doing wrong? Thanks Sean Bowes This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan & Co. Incorporated, its subsidiaries and affiliates. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
