Kodo logging issue on IBM WAS 5.0

Question

Hi All,
Thank you for reading this. I could use a good advice here, I have been
banging my head against wall for a while ...
We have a J2EE application that uses Kodo 2.4.2 with IBM WAS 5.0. Due to
'class not found' problems (related to registering the PMfactory with
JNDI, I reckon), I was forced to use a Websphere extension classloader to
load Kodo. (deploy Kodo libraries to c:\program
files\websphere\AddServer\lib\ext )
That is good and well, however now I want to configure logging (Log4J) for
Kodo. To do that, I have tried (feels like I have tried it all ;-)) to put
the log4j.properties to:
c:\program files\websphere\AddServer\properties\log4j.properties
c:\program files\websphere\AddServer\lib\ext\log4j.jar!log4j.properties
c:\program files\websphere\AddServer\lib\ext\log4j.properties
inside of the Kodo.jar (desperate people do desperate things ;-))
log4j.properties is also referenced as a part of shared library
Just for completness, log4j.properties also exists in Java utility jar
file that is part of EAR file (although that probably would not help the
Websphere extension classloader-loaded classes)
I have also tried to define the log4j.configuration in my startServer.bat:
SET LOG4J=-Dlog4j.configuration=file:/c:/log4j.properties
echo LOG4J set %LOG4J%
"%JAVA_HOME%\bin\java" %LOG4J% %WAS_TRACE%
To initialize Log4J differently. Yes, you guessed right, that damn thing
still does not work. What am I missing???
What exactly is happening when Kodo/Log4j configures the logging?
It may sound like just a nuisance, but it is actually quite important,
because we are just inch from production and need to get rid of heaps of
debuging messages (including the annoying SQL Server induced close cursor
exceptions). It just would not shut up!!! ;-))))
Any idea how to silence the bloody thing beside turning off the power? ;-)
Thank you,
Petr

Answer 1

Petr-
The easiest thing to do would be to put some code in your application
that will give information on the definitive location of the
log4j.properties file. E.g.:
System.out.println (getClass().getClassLoader().getResource("/log4j.properties"));
Other than that, note that there are a variety of System properties you
can use to override the logging system that will be use. The Kodo 2.5
documentation covers this a bit better than the 2.4 docs:
http://www.solarmetric.com/Software/Documentation/2.5.0b1/docs/manual.html#ref_guide_logging
Finally, note that some application servers use log4j internally for
logging, and configure it differently (e.g., JBoss uses a log4j.xml
file, rather than a log4j.properties file). You might want to check the
documentation of your appserver to determine if there is an alternate
mechanism for configuring log4j.
Let us know if you still need help with this.
In article <[email protected]>, Petr Bulanek wrote:
Hi All,
Thank you for reading this. I could use a good advice here, I have been
banging my head against wall for a while ...
We have a J2EE application that uses Kodo 2.4.2 with IBM WAS 5.0. Due to
'class not found' problems (related to registering the PMfactory with
JNDI, I reckon), I was forced to use a Websphere extension classloader to
load Kodo. (deploy Kodo libraries to c:\program
files\websphere\AddServer\lib\ext )
That is good and well, however now I want to configure logging (Log4J) for
Kodo. To do that, I have tried (feels like I have tried it all ;-)) to put
the log4j.properties to:
c:\program files\websphere\AddServer\properties\log4j.properties
c:\program files\websphere\AddServer\lib\ext\log4j.jar!log4j.properties
c:\program files\websphere\AddServer\lib\ext\log4j.properties
inside of the Kodo.jar (desperate people do desperate things ;-))
log4j.properties is also referenced as a part of shared library
Just for completness, log4j.properties also exists in Java utility jar
file that is part of EAR file (although that probably would not help the
Websphere extension classloader-loaded classes)
I have also tried to define the log4j.configuration in my startServer.bat:
SET LOG4J=-Dlog4j.configuration=file:/c:/log4j.properties
echo LOG4J set %LOG4J%
"%JAVA_HOME%\bin\java" %LOG4J% %WAS_TRACE%
To initialize Log4J differently. Yes, you guessed right, that damn thing
still does not work. What am I missing???
What exactly is happening when Kodo/Log4j configures the logging?
It may sound like just a nuisance, but it is actually quite important,
because we are just inch from production and need to get rid of heaps of
debuging messages (including the annoying SQL Server induced close cursor
exceptions). It just would not shut up!!! ;-))))
Any idea how to silence the bloody thing beside turning off the power? ;-)
Thank you,
Petr
Marc Prud'hommeaux [email protected]
SolarMetric Inc. http://www.solarmetric.com