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]
