Oh, I'm so embarrased! I should have actually LOOKED at our tomcat.bat/sh
files. We had created a 'realm' for our own custom authentication. The new
classes are in the same packages as our webapp classes, so someone added
our webapp/WEB-INF/classes directory to the classpath for tomcat. Very bad!
Our classes were being loaded by the parent classloader and when we tried
to access a 3rd party class within the webapp's lib it couldn't be found. I
moved these classes into a separate jar, put that jar in tomcat/lib,
removed the classpath modification, and everything works great.

As a suggestion to Joe, you may want to put some trace messages in your
classes and print out the class loaders. Another thing I did was install a
clean version of tomcat and create a very simple webapp with some jsp that
calls a bean that calls a 3rd party class. I also made sure there was
nothing in my CLASSPATH. This just verified that it was my problem and not
Tomcat's.

Thanks for the help. I learned a lot on this thread of discussion. Sorry it
was at the expense of others. :o)
Dave





"Craig R. McClanahan" <[EMAIL PROTECTED]> on 07/25/2001 06:34:18 PM

Please respond to [EMAIL PROTECTED]

To:   [EMAIL PROTECTED]
cc:

Subject:  Re: question about WEB-INF/lib



The other side of the coin is that I know for a fact that web apps using
JAR files in /WEB-INF/lib can run under Tomcat 3.2 (example:  download
Struts, deploy the struts-example.war application, restart Tomcat, and run
it).  So it's *not* as simple as saying "Tomcat does not know how to load
application classes from /WEB-INF/classes or /WEB-INF/lib/*.jar files".

You will also find that Tomcat can indeed load applications from
/WEB-INF/classes for at least some users -- otherwise, none of the
"/examples" servlets or jsp pages shipped with Tomcat would work at all.

Your webapp sounds like it is set up correctly ... now let's look at your
environment.  I'm going to start with the assumption that you have *not*
tried to manually manipulate your CLASSPATH to put the webapp's
/WEB-INF/classes directory (or any JAR files under
/WEB-INF/lib) specifically on it.

The most critical issue (and the one that will definitely cause
ClassNotFoundException errors) is to have a copy of one of the same
application classes (or the JDBC driver classes in your case) *also*
visible through the CLASSPATH (since you're using Tomcat 3.2 this
matters), in $TOMCAT_HOME/lib, or in your Java extensions directory
($JAVA_HOME/jre/lib/ext).

The reason this causes you grief is that, because of the way Java class
loading works in Tomcat 3.2, the "shared" version of the class will be
loaded.  And, this "shared" copy (because it was loaded from a classloader
that is the parent of the webapp class loader) cannot itself load classes
from the webapp classloader (in class loading terms, delegation can go
*up* the classloader hierarchy but not *down*).

If this is not the cause of the problem, the only way to resolve it is to
create a minimal webapp that illustrates the problem, and post it along
with a bug report.  However, my experience has been that CLASSPATH issues
are by far the most common cause of ClassNotFoundException problems that
Tomcat users run into.

Craig McClanahan

PS:  Classpath problems are so prevalent that Tomcat 4's startup scripts
totally ignore the user's CLASSPATH variable.  If you want to share JARs
across multiple webapps, put them in $TOMCAT_HOME/lib -- otherwise, put
them in the /WEB-INF/lib directory of the webapp that needs them.  This
strategy also works in Tomcat 3.2 (as long as you don't have so many JARs
in $TOMCAT_HOME/lib that the environment variable length of your OS is
exceeded).



On 25 Jul 2001, Joseph D Toussaint wrote:

> I'm pretty certain that my war file is set up correctly.  In my
> WEB-INF/lib directoy I have jdbc jar file that tomcat can't find and the
> tomcat user manual for deploying tomcat applications says
>
>
>     WEB-INF/lib/ - This directory contains JAR files that contain Java
>     class files (and associated resources) required for your
>     application, such as third party class libraries or JDBC drivers.
>
>
>
> My servlets are in the WEB-INF/classes directory and the same document
> says
>
>
>     WEB-INF/classes/ - This directory contains any Java class files (and
>     associated resources) required for your application, including both
>     servlet and non-servlet classes, that are not combined into JAR
>     files.
>
>
>
> Aside from that I have read the Servlet 2.3 spec on this topic and it
> says this about the WEB-INF/lib
>
>
>     The /WEB-INF/lib/*.jar area for Java ARchive files. These files
>     contain servlets, beans, and other utility classes useful to the web
>     application. The web application class loader can load class from
>     any of these archive files.
>
> Here is what it says about the WEB-INF/classes directory
>
>     The /WEB-INF/classes/* directory for servlet and utility classes.
>     The classes in this directory are available to the application class
>     loader.
>
>
> Now to re-cap I have a jdbc jar file in WEB-INF/lib and I'm trying to
> access it from a servlet in WEB-INF/classes
>
>     After looking at the spec again it says the container "can load
>     classes from any of these archive files".  I suppose this could mean
>     that it is optional for the container to load the classes found in
>     this directory, in which case tomcat is adhearing to the spec and it
>     is not required to load all the classes it finds there.
>
>
>
> If you see something that I'm mis-interpting please let me know.
>
> thanks
>
> joe
>
>
>
>
>
> On 25 Jul 2001 11:39:11 -0700, Craig R. McClanahan wrote:
> >
> >
> > On Wed, 25 Jul 2001 [EMAIL PROTECTED] wrote:
> >
> > >
> > > This is my workaround as well, but it is not a very good solution. I
often
> > > have multiple webapps running that need different versions of the
same jar
> > > file. This becomes a real pain.
> > > Thanks,
> > > Dave
> > >
> >
> > If you have to modify the CLASSPATH to make classes inside JAR file in
a
> > /WEB-INF/lib directory available, your webapps are set up incorrectly.
> > In fact, doing this will make a lot of other things (like automatic
> > reloading on updated classes) fail miserably.
> >
> > One good source of information about how to organize your web
applications
> > is the "Application Developer's Guide" that is shipped with Tomcat
(both
> > 3.2 and 4.0).  Additionally, you should consider the Servlet
Specification
> > (version 2.2 or 2.3, depending on which Tomcat you're running) to be
> > ***required reading***, because that's where the requirements for web
> > applications are actually defined.  You can get the spec from:
> >
> >   http://java.sun.com/products/servlet/download.html
> >
> > Craig McClanahan
> >
>
>
>
> --
> ##############################
> # Joseph Toussaint           #
> # Caribou Lake Software      #
> # http://www.cariboulake.com #
> # [EMAIL PROTECTED]   #
> # 952-837-98029              #
> ##############################
>
>







Reply via email to