On Wed, 27 Nov 2002, Subir Sengupta wrote:
> Date: Wed, 27 Nov 2002 13:27:10 -0800 > From: Subir Sengupta <[EMAIL PROTECTED]> > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > To: 'Tomcat Users List' <[EMAIL PROTECTED]> > Subject: RE: Classloader/Classpath problem > > I'm very familiar with that doc. > > The question is - If the class loader loaded the jar, then why would my init > app throw a NoClassDefFoundError exception. And not throw it when the jar > is in the classpath. > Class loaders are pretty much the wierdest thing about Java. There are several issues that might be related to this. * Tomcat's standard startup script totally ignore your CLASSPATH variable, and sets what it needs. (See mailing list archives for a discussion of why it works this way, and will continue to work this way as long as *I* have any say about it.) If you are modifying this startup script in any way, all bets are off -- you're on your own for figuring out what is going on here. * Putting JARs in the runtime extensions directory (under 4.0 that means $JAVA_HOME/jre/lib/ext, for 4.1 that means $CATALINA_HOME/common/endorsed) can cause problems because these directories have a higher class loading priority than any of the Tomcat class loaders. * If a class itself cannot be found, you will usually get a ClassNotFoundException. You're getting a NoClassDefFoundError exception instead, which means that your class was found, but one of the classes *it* depends on (i.e. imports) can not be found. Double check that the classes your Syslog class depends on are available. * If the class you are talking about is in the common class loader (i.e. in common/lib) but the dependent class is in /WEB-INF/lib, you are guaranteed to get this error. Classes know which class loader they are loaded from, and can look *up* the class loader hierarchy, but not *down*. * It is possible (by using the Thread context class loader) to program your way out of the issue raised in the previous point, but this has to be done deliberately. * If you are using JDK 1.4.1, you will find that this JVM has started enforcing rules related to unpackaged classes -- in particular, it's no longer allowed to "import" an unpackaged class, or to load one dynamically (this is why you will now have problems with unpackaged JavaBeans in <jsp:useBean> and things like that). * Early Tomcat 4.0.x versions had some bugs in the webapp class loader that sometimes manifested themselves with NCFE problems. Be sure you are testing against the latest production version (4.0.6 or 4.1.12). > Subir Craig -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
