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 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
