Hi Randy, Thanks for you help with answers. I think the bug with not allowing classes to load in the webapp classloader is a bug in Tomcat 4.0.2 and 4.0.3, and is fixed in 4.0.4-b1.
Tomcat 3.3.x doesn't restrict any jars from being loaded in the webapp classloader. However, because Tomcat 3.3.x follows the Java2 delegation model (i.e. delagate to your parent classloader first, then look for the class locally) you can't override classes that also appear in parent classloaders. Tomcat 4.x implements the Servlet 2.3 spec recommendation that the web application classloader look for classes locally first, before delegating to their parent classloader. However, the Servlet 2.3 spec also has a requirement that certain classes not be overridable, such as the javax.servlet classes. It was in attempting to implement this requirement that Tomcat 4.0.2 and 4.0.3 were too restrictive. Tomcat 4.0.4-b1 provides a better implementation of this requirement. Cheers, Larry > -----Original Message----- > From: Randy Layman [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, March 20, 2002 6:44 AM > To: 'Tomcat Users List' > Subject: RE: Tomcat 3.2.1, 3.2.3, 3.2.4a > > > > The Tomcat 3.2 series had a number of issues with > indirect loading of classes - the servlet or class would call > one of Sun's classes to load a class (like JNDI). The > problem was that the web app's class loader wasn't visible to > the system classes. In Tomcat 3.2 you can put all your > classes (servlets, utility classes, beans, etc) into a jar > file in TOMCAT_HOME/lib and this should work - although > dynamic class reloading will not work! > > Tomcat 3.3 works much better in this regard and classes > placed into the WEB-INF/classes and jars in WEB-INF/lib > should work just fine with one > exception: there are certain classes that Tomcat doesn't > allow you to load in the webapp (I don't really understand > why, but they do it). Apparently the list is a little to > long in the current release and the Tomcat 3.3.1 release will > allow more classes to be loaded from web app jar files. If > you search the list archives for articles referencing Tomcat > 3.3.1 you should be able to find the messages about this > problem. To get around this you can place the classes in > TOMCAT_HOME/lib/apps or TOMCAT_HOME/lib/common. > > Randy > > > > -----Original Message----- > > From: Daniel Bruce Lynes [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, March 19, 2002 7:51 PM > > To: [EMAIL PROTECTED] > > Subject: Tomcat 3.2.1, 3.2.3, 3.2.4a > > > > > > I've now tried using the WEB-INF/lib directory with all of > > the above versions > > to no avail. No matter what, certain lib files I put into > > the WEB-INF/lib > > directory won't load. Also, specific class files within > > specific jar files > > won't load; extracting them into the WEB-INF/classes > > directory doesn't help. > > Putting everything into the system lib directory works until > > I get to the > > point where I need to run a servlet. Then I'm SOL, as it > > expects to find the > > servlet class files under the WEB-INF/lib or WEB-INF/classes > > directory. > > > > I have also tried with the following JDK's: > > > > Sun JDK 1.3.1-b24 > > Sun JDK 1.3.1_02 > > Blackdown JDK 1.3.0 FCS > > > > For some quick examples, the following fail every time: > > > > jnp-client.jar comes with JBoss 2.4.x (I'm using 2.4.4) > > jnp-client.jar: org.jnp.interfaces.NamingContextFactory > > > > The home interface from my jar file that I've archived up for the > > application, but other classes within the same jar file > load up fine. > > > > log4j is v1.1.3 > > log4j.jar: Cannot find the context for .... (this works in > > 3.2.4a and 3.2.3 > > but not in 3.2.1); it is fixed by including the > > $TOMCAT_HOME/lib directory in > > the classpath, and dumping the log4j.properties file in there. > > > > jboss-client.jar comes with JBoss 2.4.x (I'm using 2.4.4) > > jboss-client.jar: fails to load proxy class when attempting > > to get the > > remote interface from the home interface (this is after I've put > > jnp-client.jar into the $TOMCAT_HOME/lib directory). > > > > I could list 3 or 4 more jar files, but I'm sure you get the > > idea, and can > > appreciate the fact that this isn't a complicated setup. I'm > > wondering if > > there's something special I have to do in my startup scripts? > > > > Also, I'm running Linux kernel v2.2.19, and glibc 2.2.3. > > > > Thanks in advance for any help you might be able to offer. > > > > I just want to make sure this is a bug, and not a > > configuration error, before > > submitting it to bugzilla. > > > > -- > > To unsubscribe: > <mailto:tomcat-user-> [EMAIL PROTECTED]> > > For > additional commands: > <mailto:[EMAIL PROTECTED]> > > Troubles with the list: > <mailto:[EMAIL PROTECTED]> > > > > -- > To > unsubscribe: <mailto:[EMAIL PROTECTED]> > For additional commands: <mailto:[EMAIL PROTECTED]> > Troubles with the list: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]>
