Re: [Slightly OT] CLASSPATH variable in catalina.sh
I don't think
${catalina.home}/common/classes/log4j.properties
is a valid classpath element.
An excerpt from the java tools doc says:
How the Java Launcher Finds User Classes:
User classes are classes which build on the Java platform. To find user
classes, the launcher refers to the user class path -- a list of
directories, JAR archives, and ZIP archives which contain class files.
So - if you *really* want to go this road -
${catalina.home}/common/classes would probably be better.
However, since (IIRC) tomcat doesn't ship with axis you probably have it
in your webapp's WEB-INF/lib. WEB-INF/classes takes precedence so if
the properties file is there it should be picked up first. Ultimately,
I guess it all depends on the relative places in the classloader
hierarchy of the log4j and axis jars.
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/class-loader-howto.html
HTH,
Jon
Robert Bateman wrote:
While debugging a log4j problem this afternoon... I happened to attempt
to rearrange the contents of my CLASSPATH on my Fedora Core 2 machine in
order to insure a correct log4j.properties file is being loaded by TC.
To insure the proper file is loaded, I placed
${catalina.home}/common/classes/log4j.properties as the *first* entry in
the CLASSPATH that catalina.sh passes into the bootstrap process.
Looking at 'ps -aef | grep java' I see my properties file listed first
in the classpath.
HOWEVER, it appears that classloader sun.misc.Launcher$AppClassLoader in
Java 1.4.2_05 doesn't honor the -classpath in it's entirety - as
1.4.2_05 *never* loads the log4j.properties file that's in the
classpath. Instead - it decides to load the log4j.properties file that
is contained in the axis-ant.jar file.
Am I crazy Or did I do something wrong???
Bob
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Slightly OT] CLASSPATH variable in catalina.sh
Sorry. Didn't see your previous post relating to the use of the
-security flag. I'm not sure why it should make a difference in this
case but in the past I've found that using
CATALINA_OPTS=-Djava.security.debug=access,failure
and starting tomcat at the command line with:
catalina run -security 2 access.err access.out
to be useful for debugging security issues.
J
Jon Wingfield wrote:
I don't think
${catalina.home}/common/classes/log4j.properties
is a valid classpath element.
An excerpt from the java tools doc says:
How the Java Launcher Finds User Classes:
User classes are classes which build on the Java platform. To find user
classes, the launcher refers to the user class path -- a list of
directories, JAR archives, and ZIP archives which contain class files.
So - if you *really* want to go this road -
${catalina.home}/common/classes would probably be better.
However, since (IIRC) tomcat doesn't ship with axis you probably have it
in your webapp's WEB-INF/lib. WEB-INF/classes takes precedence so if
the properties file is there it should be picked up first. Ultimately,
I guess it all depends on the relative places in the classloader
hierarchy of the log4j and axis jars.
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/class-loader-howto.html
HTH,
Jon
Robert Bateman wrote:
While debugging a log4j problem this afternoon... I happened to attempt
to rearrange the contents of my CLASSPATH on my Fedora Core 2 machine in
order to insure a correct log4j.properties file is being loaded by TC.
To insure the proper file is loaded, I placed
${catalina.home}/common/classes/log4j.properties as the *first* entry in
the CLASSPATH that catalina.sh passes into the bootstrap process.
Looking at 'ps -aef | grep java' I see my properties file listed first
in the classpath.
HOWEVER, it appears that classloader sun.misc.Launcher$AppClassLoader in
Java 1.4.2_05 doesn't honor the -classpath in it's entirety - as
1.4.2_05 *never* loads the log4j.properties file that's in the
classpath. Instead - it decides to load the log4j.properties file that
is contained in the axis-ant.jar file.
Am I crazy Or did I do something wrong???
Bob
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Slightly OT] CLASSPATH variable in catalina.sh
While debugging a log4j problem this afternoon... I happened to attempt
to rearrange the contents of my CLASSPATH on my Fedora Core 2 machine in
order to insure a correct log4j.properties file is being loaded by TC.
To insure the proper file is loaded, I placed
${catalina.home}/common/classes/log4j.properties as the *first* entry in
the CLASSPATH that catalina.sh passes into the bootstrap process.
Looking at 'ps -aef | grep java' I see my properties file listed first
in the classpath.
HOWEVER, it appears that classloader sun.misc.Launcher$AppClassLoader in
Java 1.4.2_05 doesn't honor the -classpath in it's entirety - as
1.4.2_05 *never* loads the log4j.properties file that's in the
classpath. Instead - it decides to load the log4j.properties file that
is contained in the axis-ant.jar file.
Am I crazy Or did I do something wrong???
Bob
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
