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 03:14:26 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 hoju@visi.com  2005-02-07 04:14 -------
Remy,

That's a lot of words for having "nothing else to say", especially when you are
the one who strayed off in to this discussion when all I was trying to do was
comment about context isolation, albeit from Log4j's perspective, which I don't
think is exactly off-topic in this report even if it is about JDK 1.4 logging.

In any case, can you address why Tomcat 5.0.xx and 5.5.x ship with
commons-logging-api.jar and not commons-logging.jar?  Why is the former
necessary?  As I understand it, the only diffence is the exclusion of
"org.apache.commons.logging.impl.Log4JLogger" and 
"org.apache.commons.logging.impl.AvalonLoggersupport".  Is it a technical
decision or a philisophical one?  If a technical one, is the reason to avoid
commons-logging discovery issues if Log4j or Avalon is somewhere in a child
classloader visible to discovery, but invisible to the server, and therefore, to
avoid NoClassDefFoundError's?  You say commons-logging isn't broken, but doesn't
this just typify the problem with commons-logging?  Don't let me put words in
your mouth, but I can't come up with any other rational reason for confusing the
situation with two nearly identical, but differently functioning, jars from the
commons-logging project.  Why would Log4j want to be involved in something
already so broken other than making sure we generally interoperate with it
(which we did for the commons-logging-1.0.4 release, so please stop claiming
that the Log4j is some rogue uncooperative project).

BTW, how is a logging alternative like UGLI (which, as Ceki explained, is an
interal fallback logging implementation that happens to double as generic API)
considered a commons-logging "fork"?  My understanding of a "fork" is starting
with an existing API and modifying it so it is incompatible with the original. 
UGLI was written from scratch and not based on commons-logging so it is quite
literally not a "fork" but an "alternative".  That is, unless you consider any
similarily functioning software as a "fork", which would make competing
application servers "forks" or XOM a "fork" of "JDOM".  They are "alternatives",
not "forks".  If you are talking about unifying alternatives, are you saying
that the commons-logging project would accept moving to an UGLI-like concept and
get rid of the discovery?  I remain unconvinced.  So, start the dialog and
convince me and everyone else.  If you are unwilling to do this after making
clear the consternation you have over a lack of a unified logging API, then you
are just blowing hot air.  Let's see some action from someone with a lot of pull
in the Jakarta sphere.  We're all waiting.


Jake

-- 
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