Kodo, JRun, and logging

Question

Hi,
I'm trying to run my Kodo JDO application in a JRun4 J2EE server. I'm
having a problem getting logging to work, and I've discovered what's
happening.
As it happens, JRun is using the commons logging facility itself, and
initializes an older version of Log4j before my classes are even loaded.
Thus, any log4j.properties file I specify (or even if I change the name to
something else and specify it via the log4j.configuration system property)
is ignored because by the time the web app is loaded, the system
log4j.properties have already been initialized and mine are ignored.
The solution offered on the JRun support site is to rewrite your
log4j-enabled app to use custom logging (in a JRun-proprietary format),
but that's obviously not an option for me here because the logging is
internal to Kodo's classes.
What I'm wondering is this: is there a setting I can specify something in
my kodo.properties file or in some other location that will tell Kodo to
instantiate its own private log4j instance instead of using the system's?
Or is there some other way to force Kodo to ignore the existing JRun
logging facility?
Any thoughts would be much appreciated.
Thanks,
Bill

Answer 1

Oops! The my posting didn't get put up exactly as I typed it. Instances of
"$/servers/lib" should instead be "JRUN_HOME/servers/lib" where
"JRUN_HOME" is the directory that JRun is installed in.
Bill
William Korb wrote:
Marc,
Thanks for the feedback. I experimented a bit (quite a bit, actually) and
found a configuration that works without having to implement a custom
logging mechanism.
First off, in order to use the version of Log4j that came with Kodo
instead of the old version that is bundled with JRun (and embedded in one
of JRun's own JAR files, BTW - ick!), I had to make a couple of JRun
configuration changes.
1. Install log4j-1.2.6.jar in $/servers/lib
2. Install log4j.properties in $/servers/lib
3. Create a .../WEB-INF/jrun-web.xml file with the following contents:
<?xml version ="1.0"?>
<!DOCTYPE jrun-web-app SYSTEM "jrun-web.dtd">
<jrun-web-app>
<load-system-classes-first>false</load-system-classes-first>
</jrun-web-app>
This last step is the critical one - it tells JRun to put
$/servers/lib in the CLASSPATH ahead of the JRun system jars
(which include the old version of Log4j, etc.).
The down-side of this configuration is that every JRun server instance
will use the same Log4j setup, but I can live with that.
Lastly, I tweaked the log4j.properties file to send my Kodo log entries
into a separate file (otherwise they ended up intermingled with the
standard JRun log entries):
# Normal Kodo logging configuration
log4j.rootCategory=INFO, console
# Custom verbosity levels on a per-category basis
log4j.category.com.solarmetric.kodo.impl.jdbc.SQL=DEBUG, kodolog
log4j.category.com.solarmetric.kodo.impl.jdbc.JDBC=INFO, kodolog
log4j.category.com.solarmetric.kodo.impl.jdbc.Schema=INFO, kodolog
log4j.category.com.solarmetric.kodo.Performance=INFO, kodolog
log4j.category.com.solarmetric.kodo.MetaData=INFO, kodolog
log4j.category.com.solarmetric.kodo.Enhance=INFO, kodolog
log4j.category.com.solarmetric.kodo.Query=DEBUG, kodolog
log4j.category.com.solarmetric.kodo.Runtime=DEBUG, kodolog
# Set appender specific options.
log4j.appender.kodolog=org.apache.log4j.RollingFileAppender
log4j.appender.kodolog.File=/tmp/javatest-kodo.log
log4j.appender.kodolog.Append=true
log4j.appender.kodolog.MaxFileSize=10mb
log4j.appender.kodolog.MaxBackupIndex=9
log4j.appender.kodolog.layout=org.apache.log4j.PatternLayout
log4j.appender.kodolog.layout.ConversionPattern=%-5r %-5p [%t] %c - %m%n
log4j.appender.console=org.apache.log4j.ConsoleAppender
log4j.appender.console.layout=org.apache.log4j.PatternLayout
log4j.appender.console.layout.ConversionPattern=%-5r %-5p [%t] %c - %m%n
If Macromedia ever gets around to putting out another release of JRun,
hopefully they'll address these poor design decisions.
Bill
Marc Prud'hommeaux wrote:
Bill-
I assume that you don't have access to JRun's log4j properties file so
you can use it to set the Kodo logging parameters.
You might be able to coerce JRun into using some logger of your own
devising with the "org.apache.commons.logging.LogFactory" system
property. E.g., see:>>
>
http://www.solarmetric.com/Software/Documentation/3.0.0RC4/docs/manual.html#ref_guide_logging_custom
There is currently no way to tell Kodo to use a separate logger on it's
own: you will need to do it via the commons logging framework.
Let us know if we can offer some more suggestions, if this one doesn't
work.
In article <[email protected]>, William Korb wrote:
Hi,
I'm trying to run my Kodo JDO application in a JRun4 J2EE server. I'm
having a problem getting logging to work, and I've discovered what's
happening.
As it happens, JRun is using the commons logging facility itself, and
initializes an older version of Log4j before my classes are even loaded.
Thus, any log4j.properties file I specify (or even if I change the name
to
something else and specify it via the log4j.configuration systemproperty)
is ignored because by the time the web app is loaded, the system
log4j.properties have already been initialized and mine are ignored.
The solution offered on the JRun support site is to rewrite your
log4j-enabled app to use custom logging (in a JRun-proprietary format),
but that's obviously not an option for me here because the logging is
internal to Kodo's classes.
What I'm wondering is this: is there a setting I can specify something in
my kodo.properties file or in some other location that will tell Kodo to
instantiate its own private log4j instance instead of using the system's?
Or is there some other way to force Kodo to ignore the existing JRun
logging facility?
Any thoughts would be much appreciated.
Thanks,
Bill
Marc Prud'hommeaux [email protected]
SolarMetric Inc. http://www.solarmetric.com