RE: RE:Commons-logging WSAD5.1

[Srilatha Alase <sa...@issintl.com>]

Hi Robert,
  Thank you for your input..

When I changed the commons-logging.properties to have the following entry:-
org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4jLogger

Now I'm getting an error on startup 

Caused by: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: java.lang.ClassNotFoundException: org.apache.commons.logging.impl.Log4jLogger (Caused by java.lang.ClassNotFoundException: org.apache.commons.logging.impl.Log4jLogger) (Caused by org.apache.commons.logging.LogConfigurationException: java.lang.ClassNotFoundException: org.apache.commons.logging.impl.Log4jLogger (Caused by java.lang.ClassNotFoundException: org.apache.commons.logging.impl.Log4jLogger))
	at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:543)
...


I do have commons-logging-1.0.4.jar in the server classpath,also added a custom classloader in WSAD 5.1
to use the commons-logging-1.0.4.jar.

Any Ideas?
Thanks!

-----Original Message-----
From: robert burrell donkin
[mailto:robertburrelldonkin@blueyonder.co.uk]
Sent: Tuesday, January 31, 2006 3:37 PM
To: Jakarta Commons Users List
Subject: Re: RE:Commons-logging WSAD5.1


On Tue, 2006-01-31 at 14:47 -0600, Srilatha Alase wrote:
> Hi,
>   I have a problem with DEBUG messages being printed in the SystemOut.log file.
> 
> we have migrated from WSAD version 4 to WSAD 5.1 and we are encountering that commons-logging does not consider
> the level assigned in the log4j.properties.It seems that It is reading the log4j.properties that I provided
> since i kept a pattern to print and it prints in the pattern specified but somehow ignores the priority.

commons-logging (JCL) is a bridge: all it does it work out which logging
system it should bridging to and then delegate all logging to the
logging system. with a bridge there are two factors to consider. the
first is a misconfiguration of the bridge, the other is a
misconfiguration of the logging system bridged to.

the easiest way to test whether JCL is logging to the logging system you
want is to check whether the output is logging to the right place and is
formatted in the expected way. if so, then the problem lies in the
configuration of the logging system (log4j, in this case). if the output
is misplaced or appears in an unusual format then it's likely that JCL
has failed to understand which logging system it should be bridging to.

> we have commons-logging.properties with the following entry :-
> org.apache.commons.logging.LogFactory=org.apache.commons.logging.impl.Log4jFactory

that's deprecated. the following is now preferred: 

org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4jLogger

- robert


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org

RE: RE:Commons-logging WSAD5.1

[robert burrell donkin <ro...@blueyonder.co.uk>]

On Tue, 2006-01-31 at 17:36 -0600, Srilatha Alase wrote: 
> Hi Robert,
>   Thank you for your input..
> 
> When I changed the commons-logging.properties to have the following entry:-
> org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4jLogger
> 
> Now I'm getting an error on startup 
> 
> Caused by: org.apache.commons.logging.LogConfigurationException: 
> org.apache.commons.logging.LogConfigurationException: java.lang.ClassNotFoundException: org.apache.commons.logging.impl.Log4jLogger 
> ...

the stack's pretty clear: org.apache.commons.logging.impl.Log4jLogger
cannot be loaded. the open question is why it can't be loaded. 

> I do have commons-logging-1.0.4.jar in the server classpath,also added a custom classloader in WSAD 5.1
> to use the commons-logging-1.0.4.jar.

the most likely explanation is that there are multiple JCL jars in your
classpath including an API jar. debugging a complex classloader
configuration (such as is found in modern J2EE containers) with multiple
JCL jars requires specialist knowledge and expertise. 

so, the easiest approach is usually just to remove all JCL jars (so the
application fails with a java.lang.ClassNotFoundException for either
org.apache.commons.logging.Log or
org.apache.commons.logging.LogFactory). then add one full jar
(commons-logging-1.0.4.jar) back and see if it works.

alternatively, we've been working hard on JCL 1.1. this has a lot of
improvements including better diagnostics. a release candidate is
available from http://people.apache.org/~rdonkin/commons-logging/.
please read the release notes carefully. remove all old jar's (by
following the process outlined above) and then try the new jar instead.
if it doesn't work, try running with the system property
org.apache.commons.logging.diagnostics.dest=STDERR (or STDOUT).

- robert


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org