Thank you for your quick reply. I think I understand the distinction you
make between a class being available and a class being loaded, although
it is a bit confusing.  I suspect that if I understand this clearly, it
will help me track down the cause of my problem.

Given the Tomcat ClassLoader hierarchy diagram in the documentation and
your clarification below, is the following correct?

The Catalina ClassLoader in server/lib creates Webapp1 ClassLoader
specifically for webapp1.  The parent classloader of Webapp1 ClassLoader
is NOT set to Catalina ClassLoader but rather to Shared ClassLoader, so
requests from webapp1 to load classes are never delegated to Catalina
ClassLoader.  Thus a reference to a Class in server/lib in Webapp1 will
result in a ClassDefNotFound error.  However, the classes in sever/lib
ARE aware of WebApp1, and may call methods in Webapp1 and pass in
references to themselves.  When this happens, Webapp1 is now working
with an implementation of a class in server/lib.  I assume, however,
that the only way for this to work in practice is that these specific
implementations are referenced in Webapp1 as Interfaces which are
defined NOT in server/lib, but rather by jars higher up in hierarchy,
such as common/lib.

If this understanding is true, then
a) if my webapp code has any specific reference (e.g. the Class name is
in my code as a variable or parameter type) to a class in server/lib, I
should get a ClassDefNotFoundError.
b) however, if my webapp has a reference to an Interface defined in
common/lib and at runtime is handed a Class that implements this class,
I may not get a ClassDefNotFoundError.

Regards,
Gary

-----Original Message-----
From: Caldarale, Charles R [mailto:[EMAIL PROTECTED] 
Sent: Thursday, October 16, 2008 6:55 PM
To: Tomcat Users List
Subject: RE: Classes in tomcat\server\lib folder sometimes are visible
to web application

> From: Gary Hirschhorn [mailto:[EMAIL PROTECTED]
> Subject: Classes in tomcat\server\lib folder sometimes are
> visible to web application
>
> According to this documentation, classes in this jar
> should be TOTALLY invisible to web applications.

That's not quite the case.  Classes outside of a given classloader's
branch can not be *loaded* by that classloader.  However, if references
to instances of such "outside" classes are made available to code from
the classloader branch of interest, that code can use those objects.

Nearly all of Tomcat's code, including the classloaders,
request/response wrappers, servlet API handlers, etc., are in
server/lib, yet are obviously used by application servlet code.

> So I understand why it does not work (class should not
> be visible), but why does it ever work?

Without seeing the code, it's difficult to even speculate.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to