tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 33143] - [PATCH] Java 1.4 loggers per context
Date Mon, 07 Feb 2005 15:04:27 GMT
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 ceki@apache.org  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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message