My experience with 3.2 (or 3.2.1 since you want the fix for the bug in the security) has been that, under our load testing, it has being quite reliable and stable. I can't say yet about a production environment, but we've hit it pretty hard and had no stability issues. As to whether it solves your problem, that's someone else's baby... > -----Original Message----- > From: David Miller [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, January 16, 2001 6:48 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Upgrading to Tomcat 3.2 > > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
