tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lorenti, John" <>
Subject RE: java.lang.NoClassDefFoundError: javax/servlet/Filter
Date Fri, 24 Jan 2003 18:35:19 GMT
Thank you, Craig.
As you surmised, I'm not using the machine's environment classpath, but
instead have "hacked" the startup to include my classes just within the
Tomcat JVM.  What you describe makes sense regarding the difference between
the system class loader's classpath and the class loader Tomcat uses for
/common/lib.  As you advise, I'm moving the servlet related classes where
Tomcat is expecting them to be and removing servlet.jar from the system
loader's classpath.  I'm still trying to keep my custom, non-servlet,
classes (those shared by other applications on the machine besides Tomcat)
located elsewhere and leaving them on the system loader's classpath.  If
this doesn't work out, however, I'll let Tomcat have all of the classes and
take it from there.

Thanks again.

-----Original Message-----
From: Craig R. McClanahan []
Sent: Friday, January 24, 2003 12:54 PM
To: Tomcat Users List
Subject: RE: java.lang.NoClassDefFoundError: javax/servlet/Filter

On Fri, 24 Jan 2003, Lorenti, John wrote:

> Date: Fri, 24 Jan 2003 08:52:36 -0500
> From: "Lorenti, John" <>
> Reply-To: Tomcat Users List <>
> To: 'Tomcat Users List' <>
> Subject: RE: java.lang.NoClassDefFoundError: javax/servlet/Filter
> Tim,
> Maybe what I've done is taboo :-(  I've placed the top level directory
> has all of our custom Java classes (shared by all applications on the
> machine) on the Tomcat classpath.  Tomcat is finding my TestFilter class
> there (since I chose to leave the class there instead of placing it under
> the context's WEB-INF/classes directory) which in turn references
> javax.servlet.Filter.  Since other applications besides those within
> are using the "common" code, I'd like to keep it in one place outside of
> Tomcat's structure.  However, from what you've mentioned, it seems that I
> may need to keep any Tomcat/Servlet specific classes where Tomcat is
> expecting them to reside and not depend upon the classpath.
> If this is the case, do you think that a Tomcat-friendly solution would be
> to separate my classes into two disjoint sets - one having anything
> to servlets, and the other containing my "common" (non-Servlet specific)
> classes?  The first set would live under the context's WEB-INF hierarchy,
> and the other set living on the classpath.  If this can work, then maybe I
> can "have my cake and eat it too."
> Is there a better/more preferred way to accomplish class sharing beyond
> Tomcat's purview?

The standard Tomcat scripts ignore the classpath variable for a reason --
it is *way* to easy to get yourself into trouble, and this is just one of
those ways.

Classes on the class path (assuming you hacked the startup script to
include some) are loaded from the system class loader, and therefore
cannot see anything in common/lib (including servlet.jar).  Therefore, you
can't put a Filter, or anything else that implements from javax.servlet,
in the class path.

And, no, moving servlet.jar onto the class path someplace will just cause
you other sorts of grief.  My strong advice is to do what Tomcat wants you
to do, and put your classes where it's looking for them.
> Thank you.
> -John

Craig McClanahan

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message