Strange behaviour of Tomcat classloader

[Michael Gerdau <mg...@technosis.de>]

Hi !

I've come across an IMO strange behaviour of the Tomcat classloader
and would like to ask, wether this is intended and if yes why it is
that way.

I'm having a struts based webapp running under Tomcat 4.1.18
The webapp makes use of a DB2 database via commons-dbcp.jar
which comes with struts.
The db2java.jar (containing the DB2 JDBC driver) has been put
into the shared/lib directory.

So far so good.

I recently removed from the webapps lib dir the common-*.jar files
that are made public by tomcat in the common/lib dir, among them
commons-dbcp.jar.

After doing so Tomcat could no longer load the DB2 JDBC driver
(which are in shared/lib). After copying them to commons/lib it
once again worked.

However when I once again copy commons-dbcp.jar into the webapps
lib dir then loading the DB2 JDBC driver from shared/lib works.


My understanding is, that the DB2 JDBC driver is loaded by the
webapplication. However once the commons-dbcp.jar from the common/lib
dir has been loaded and utilized then all at a sudden shared/lib
seems no longer part of the searchpath. But when commons-dbcp.jar
is taken from the webapps lib dir then shared/lib obviously still
is in the search path.


Is this intended ?
And why ?

Thank you, best,
Michael
--
 Vote against SPAM - see http://www.politik-digital.de/spam/
 Michael Gerdau       email: mgd@technosis.de
 The few, the proud, the Windows 98 & SX owners.
 GPG/PGP-keys available on request or at public keyserver



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Strange behaviour of Tomcat classloader

[Will Hartung <wi...@msoft.com>]

> > My understanding is, that the DB2 JDBC driver is loaded by the
> > webapplication. However once the commons-dbcp.jar from the common/lib
> > dir has been loaded and utilized then all at a sudden shared/lib
> > seems no longer part of the searchpath. But when commons-dbcp.jar
> > is taken from the webapps lib dir then shared/lib obviously still
> > is in the search path.
> >
> >
> > Is this intended ?
>
> Well, it is definitely a consequence of the way that the class loaders are
> architected in Tomcat.  See:
>
>   http://jakarta.apache.org/tomcat/tomcat-4.1-doc/class-loader-howto.html

The key detail to know about Tomcat classloaders is that they are in a
heirarchy, and as Craig mentioned, those higher up in that heirarchy can not
load classes "below" them.

Normally this is not a problem but for some classes that use some kind of
reflective mechanism to load classes, this can be a real concern.

Specifically, you must be careful with any classes that load other classes
"by name", either directly or by "figuring it out" or through an XML file.
Basically, any class that loads another class that wasn't referenced at
compile time will this rear its ugly head.

Once you're comfortable and conscious of this heirarchy and this detail with
dynamic classes, your classloading life will get MUCH easier.

Unfortunately, as good as the HOWTO is, it doesn't really hilight this point
about dynamic classes.

Regards,

Will Hartung
(willh@msoft.com)




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Strange behaviour of Tomcat classloader

["Craig R. McClanahan" <cr...@apache.org>]

On Mon, 6 Jan 2003, Michael Gerdau wrote:

> Date: Mon, 06 Jan 2003 10:21:02 +0100
> From: Michael Gerdau <mg...@technosis.de>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: "tomcat-user@jakarta.apache.org" <to...@jakarta.apache.org>
> Subject: Strange behaviour of Tomcat classloader
>
> Hi !
>
> I've come across an IMO strange behaviour of the Tomcat classloader
> and would like to ask, wether this is intended and if yes why it is
> that way.
>
> I'm having a struts based webapp running under Tomcat 4.1.18
> The webapp makes use of a DB2 database via commons-dbcp.jar
> which comes with struts.
> The db2java.jar (containing the DB2 JDBC driver) has been put
> into the shared/lib directory.
>
> So far so good.
>
> I recently removed from the webapps lib dir the common-*.jar files
> that are made public by tomcat in the common/lib dir, among them
> commons-dbcp.jar.
>
> After doing so Tomcat could no longer load the DB2 JDBC driver
> (which are in shared/lib). After copying them to commons/lib it
> once again worked.
>
> However when I once again copy commons-dbcp.jar into the webapps
> lib dir then loading the DB2 JDBC driver from shared/lib works.
>
>
> My understanding is, that the DB2 JDBC driver is loaded by the
> webapplication. However once the commons-dbcp.jar from the common/lib
> dir has been loaded and utilized then all at a sudden shared/lib
> seems no longer part of the searchpath. But when commons-dbcp.jar
> is taken from the webapps lib dir then shared/lib obviously still
> is in the search path.
>
>
> Is this intended ?

Well, it is definitely a consequence of the way that the class loaders are
architected in Tomcat.  See:

  http://jakarta.apache.org/tomcat/tomcat-4.1-doc/class-loader-howto.html

> And why ?

The JDBC driver classes, ultimately, are loaded by the commons-dbcp code.
So, the driver has to be visible to the class loader from which
commons-dbcp is loaded, or a parent of that class loader.

In the Tomcat case, the shared class loader (loads classes from
shared/lib) is *below* the common class loader (loads classes from
common/lib).  Therefore, if you put commons-dbcp in common/lib and the
driver in shared/lib, the driver classes will not be visible.

>
> Thank you, best,
> Michael

Craig


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>