I am currently using Tomcat 3.1 and am having a problem with Tomcat recognizing jar
files in the lib folder of my webapp, i.e., Tomcat does not seem to recognize jar
files in $TOMCAT_HOME/webapps/myapp/WEB-INF/lib.  I heard (see email below) that
Tomcat 3.2 fixes this problem. Can anyone tell me (A) if they have had a similar
problem and if upgrading fixes it and (B) is Tomcat 3.2 robust enough to warrant
the upgrade? Any comments or suggestions, especially regarding Tomcat 3.2, are
greatly appreciated. Thanks in advance,

-David-


"Craig R. McClanahan" wrote:

> Steve Cote wrote:
>
> > Do I understand this right?
> >
> > If I place a jar file in a context's lib directory my classes should have
> > access to it?
>
> Yes.  To be slightly more precise, we're talking about JAR files you place in
> the WEB-INF/lib directory of your web app.
>
> > When I display System.getProperty("java.class.path") all
> > that appears is the $CLASSPATH with $TOMCAT_HOME/classes and the jar files
> > in the $TOMCAT_HOME/lib directory.
> >
>
> That is because you are trying to look at the system class path.  Tomcat creates
> a custom class loader per web app -- and it is inside the class loader that the
> makes classes in JAR files under WEB-INF/lib (as well as unpacked classes under
> WEB-INF/classes) available to your web app.
>
> When you remember that each webapp has a *different* set of classes visible to
> it, it makes sense why the system classpath cannot be used -- it's global to the
> entire Tomcat process.
>
> >
> > How do my servlets determine where it's supporting classes are? How are any
> > of my classes (especially my secure classloader) to know the location of
> > their servlet context?
> >
>
> What "secure classloader"?  The one that Tomcat creates for you?  That one is a
> private implementation that understands it belongs to a servlet context.  Any
> classloader that you create (assuming the servlet container allows you to) must
> be told where to load classes from as part of it's configuration.
>
> >
> > According to the API, I can determine that the classes I need are in the
> > "myclasses.jar" file within the "lib" directory of the WEB-INF directory
> > under the directory named the same as my myWebApp.war file, but I have no
> > idea where myWebApp.war was placed:
> >
> > $UNKNOWN_PATH/myWebApp/WEB-INF/lib/myclasses.jar
> >
> > How do I figure out $UNKNOWN_PATH?
> >
>
> Why do you care?  Tomcat takes care of all this bookkeeping for you.
>
> >
> > The end goal is to be able to create a .war file with just one set of
> > class files that can be easily deployable by simply placing the .war
> > file in the webapps directory. I'm finding that in order to deploy my
> > servlet application in Tomcat, I have to place the .war file in the
> > webapps directory, extract the particular .jar files and place them in
> > the $TOMACT_HOME/lib directory as well. This makes for difficult
> > deployment.
>
> Then you are doing something wrong, or there is something wrong with your WAR
> file, or you are still using Tomcat 3.1 (if that is the case, go directly to
> http://jakarta.apache.org and get version 3.2.1).
>
> >
> >
> > I use my own classloader as a part of an application framework, and this
> > classloader is integral to the framework, making it undesirable to by-pass
> > for servlet 2.2 deployment.
> >
> > It uses the 1.2 delegation model by over-ridding findClass() and letting
> > loadClass() delegate loading up to the parent classloaders before calling
> > the custom-written findClass(), and it still cannot find any classes in
> > the myclasses.jar. Now I know that myclasses.jar is being accessed, because
> > the rest of the framework is being loaded via the web.xml deployment file.
> >
>
> If you're using Tomcat 3.1 give up now -- it does not support the 1.2 delegation
> model at all.
>
> Under Tomcat 3.2 you need to make sure you uncomment the appropriate 1.2-related
> interceptors in order to enable support for the delegation model.
>
> Under Tomcat 4.0 you should have no problems if you do the following to
> initialize your classloader (assume this is in the init() method of your
> servlet):
>
>     ClassLoader parent = this.getClass().getClassLoader();
>     MyClassLoader myLoader =
>       new MyClassLoader(parent);    // Assumes a constructor
>             // like the standard java.lang.ClassLoader to
>             // set the parent classloader.
>
> >
> > Any help would be greatly appreciated.
> >
> > Steve Cote
> >
>
> Craig McClanahan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to