What I figured, thanks for the confirmation.
As for Velocity, there's another method of use that would work with the jar
in common/lib, but it's just a tad more involved and I was hoping to skip
it. Not a big deal, thanks again for the input.
Colin
-Original Message-
From: Craig R. McClanahan [SMTP:[EMAIL PROTECTED]]
Sent: Saturday, December 21, 2002 12:50 PM
To: Tomcat Users List
Subject: Re: Classloading question
On Fri, 20 Dec 2002, Madere, Colin wrote:
Date: Fri, 20 Dec 2002 18:11:22 -0600
From: Madere, Colin [EMAIL PROTECTED]
Reply-To: Tomcat Users List [EMAIL PROTECTED]
To: 'Tomcat Users List' [EMAIL PROTECTED]
Subject: Classloading question
I put a jar in tomcat home/common/lib/ that has some base servlet
classes
I wrote. When writing apps, I derive from these classes. Works fine.
I put the velocity.jar file in the WEB-INF/lib folder of each app for
using
the singleton model of Velocity (jakarta.apache.org/velocity) so that
each
web app has it's own engine instance. Works fine.
I try to combine the two above by putting my base class jar in the
/common/lib/ which has classes derived from the velocity.jar at the app
level and I get a class loading error since apparently classes defined
at
the container level do not look in the /WEB-INF/lib for classes. If I
put
the base class jar that's in /common/lib/ in WEB-INF/lib it works, but I
shouldn't have to do that. And the reverse also works (putting the
velocity
jar in the /common/lib/), but breaks the idea of the Velocity singleton
model since all apps on the server will be sharing the same velocity
engine
and therefore all velocity-related resources (template location, log
location, etc).
Is there any way out of having to copy my base class jar into every web
app?
The fundamental rule of Java class loaders is that they look *up* the
class loader hierarchy, not down (where the primoridial bootstrap class
loader of the JVM is considered to be at the top of the tree).
The consequence of this is that, when your classes have dependencies on
each other, the class being depended on must be loaded from the same class
loader as the dependent class, or from a class loader higher than the one
loading the dependent class.
In Tomcat terms, for example, that means it's illegal to have a dependent
class loaded from common/lib/ that depends on a class loaded from
/WEB-INF/lib, although the opposite arrangement is legal.
Regarding Velocity in particular, I'm sure you've noticed that static
variables declared in a class that's loaded from common/lib are global to
all webapps. It's possible for class libraries to program around that by
cleverly using the context class loader provided by the app server (i.e.
Tomcat makes the webapp class loader available while you're processing a
request via Thread.currentThread().getContextClassLoader()), but this must
be done deliberately by the class library author. It sounds like you
might want to suggest this to the Velocity developers, so that you can put
velocity.jar in common/lib but still have per-webapp resource definitions.
Colin
Craig
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
