The classloader behavior for webapps is specified in the servlet spec to be exactly opposite that of the normal Java2 classloading behavior. So, classes in the WebappClassLoader will *not* as the parent to load classes for it unless it can't find the class to load there first. That's one thing to remember. The other thing is that parent classloaders can't see their children, but children can see their parents. If you have a class in a parent classloader which is trying to load classes or other resources in the child classloader, you will have problems....unless you use the thread context classloader. If you use Class.forName(String) you are asking for trouble. The other version of Class.forName() which takes 3 parameters is your ticket out of this situation since you can pass it the thread context classloader to load the resource.
Anyway, I'm pretty sure you will be able to do what you are attempting to do, but without sample code, no one can help you.
Jake
At 12:59 AM 12/16/2002 -0800, you wrote:
Hello, I'm having issues with using a custom classloader in Tomcat 3.3.1. I have a need to load servlets from a runtime-determined classpath. The solution worked fine in 3.2.x. Here's what I think the problem is (let me know where my understanding is flawed):I'm pretty confident any custom classloader that tries to load servlets is doomed on newer versions of Tomcat. By this I mean, TC4x and TC5x won't work either as they employ a similar classpath paradigm as that of TC3.3x. It seems that the classloader alchemy the Jakarta people are doing to allow web application classpaths to be independent of each other and that used by the core Tomcat components is going to prevent me from instantiating a servlet via a runtime-determined classpath. A JVM process will only allow a single instance of any class type within its process space. Every JVM process has a SystemClassLoader that manages loading the core java stuff, like the String class. Any other classLoader in the process space that tries to load a String.class object after the SystemClassLoader has done so will throw a NoClassDefFoundException or some other instantiation error. What's nice about the SystemClassLoader is that any other ClassLoader in the process can check with it to see whether it's created a certain class before trying to do so, and use the one it has. A ClassLoader can also do this if it is chained with other class loaders. It needs only traverse the chain via the getParent() method and query each for the class in question. The problem with Tomcat creating its own class loaders is that my custom class loader has no way of knowing what classes they've loaded nor can I use any of those instances. So, when I try to create my servlet object, its super class, HttpServlet is also instantiated and pow, the JVM dumps a stack trace claiming it can't find resources. (sample Stack trace) ----------------------- Attempting to load class: java.lang.NoClassDefFoundError Class name: java.lang.NoClassDefFoundError 2002-12-15 23:51:07 - Ctx() : Exception in R( + /servlet/MyServlet + null) - java.lang.ExceptionInInitializerError: java.util.MissingResourceException: Can't find bundle for base name javax.servlet.http.LocalStrings, locale en_US at java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:7 07) at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:678) at java.util.ResourceBundle.getBundle(ResourceBundle.java:541) at javax.servlet.http.HttpServlet.<clinit>(HttpServlet.java) ----------------------- I'm guessing this is a nonsense error because the ResourceBundle it's looking for is in the same jar that HttpServlet is in. So, it's definitely on the classpath. Anyway, what else might I try to remedy this? Thanks. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>