DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=33143>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33143





------- Additional Comments From [EMAIL PROTECTED]  2005-02-07 16:04 -------

> The design I have in mind is that the commons-logging implementation
> for the logger you're using must reside in the same classloader
> hierarchy as the logger implementation. This is why the -api JAR is
> used. As java.logging is available in the root classloader, so does
> its commons-logging impl, and it is located next to it in the
> classloader hierarchy (from Tomcat perspective; actually, it's one
> layer above it).

Remy,

In plain English, you are admitting that JCL's discovery mechanism
does not work correctly except for java.util.logging, correct? JCL is
supposed to bridge between logging APIs, including log4j. However, in
practice it only bridges for java.util.logging and break for other
implementations residing outside the JDK.

Isn't this the plain truth?

Given the above, I don't know how you dare fling accusations at
log4j's direction and claim that JCL is problem-free. Moreover, your
contempt of a fellow Apache project is shocking.



-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to