Thanks for the reply Chuck! Hrmmmm, the -cp command-line parameter will include the JARs within Tomcat's System classloader, correct? (http://tomcat.apache.org/tomcat-6.0-doc/class-loader-howto.html) Regardless of whether the class is loaded into System or Common, I fear the issue we are encounter won't be resolved. The issue stems from the manner of how Tomcat handles classloading which throws exceptions when a class is loaded by a different classloader than the one instantiating a value for/to it. Here is another example I am dealing with:
The login module and application use Log4J for logging, so there is a private static final Logger member declared within the login module and associated classes (authorization factory to determine which authorization module to use). There are Log4J jars reside in the application as well as the common directory. These login module classes are loaded by the server, however it is not until the web application invokes the initialize/login/commit methods that an instance of Log4J's logger is instantiated and assigned to the member. Because the class was loaded by the standard classloader and being set by the webapp classloader, Log4J fails to log anything from that JAR. Here is the error log: 2007-11-16 07:02:39,011 [http-8080-2] DEBUG edu.lsu.infrastructure.java_web_utils.security.LoginServlet - Redirecting request to j_security_check log4j:ERROR A "org.apache.log4j.ConsoleAppender" object is not assignable to a "org.apache.log4j.Appender" variable. log4j:ERROR The class "org.apache.log4j.Appender" was loaded by log4j:ERROR [EMAIL PROTECTED] whereas object of type log4j:ERROR "org.apache.log4j.ConsoleAppender" was loaded by [WebappClassLoader delegate: false repositories: /WEB-INF/classes/ ----------> Parent Classloader: [EMAIL PROTECTED] ]. log4j:ERROR Could not instantiate appender named "stdout". log4j:WARN No appenders could be found for logger (edu.lsu.infrastructure.java_authorization.sam_authorization.Authorizati onFactory). log4j:WARN Please initialize the log4j system properly. I realize the solution to this is to remove the log4j JAR from the webapp, however it makes developing applications more difficult as you need to setup JARs for every project you work on, copy these over whenever a new version of Tomcat comes out, etc. </vent> Andrew R Feller, Analyst Subversion Administrator University Information Systems Louisiana State University [EMAIL PROTECTED] (office) 225.578.3737 -----Original Message----- From: Caldarale, Charles R [mailto:[EMAIL PROTECTED] Sent: Thursday, November 15, 2007 3:44 PM To: Tomcat Users List Subject: RE: Tomcat DB2 JDBC issue > From: Andrew R Feller [mailto:[EMAIL PROTECTED] > Subject: RE: Tomcat DB2 JDBC issue > > With all of this grief developing a LoginModule that is used > invoked on a Context basis, I have noticed there are lots of > issues with classes loaded by the server/common classloaders > in the LoginModule that are also needed by the webapp. For our custom JAAS login module, we simply follow the rules given at: http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html#JAASRealm In particular: "3. Place the compiled classes on Tomcat's classpath" We do this via the -cp used to launch Tomcat. This allows Tomcat and all webapps to see the necessary classes (although I don't think we have any webapps at the moment that actually look). - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]