tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sean X Bowes" <>
Subject Tomcat classloader is not working correctly
Date Thu, 09 Nov 2000 21:16:06 GMT

I am experiencing wide application problems with how the classloader works in

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 '') 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

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):
EXCEPTION DESCRIPTION: Could not convert: into an accessible Java class.
'' of class, 'class
java.lang.String' could not be converted to 'class java.lang.Class',
INTERNAL EXCEPTION: java.lang.ClassNotFoundException:

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?

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.

View raw message