On 2005-02-11 22:22:20, Craig McClanahan wrote:
> If I were inclined to change Shale's own logging APIs, I'd just switch > to JDK 1.4 logging and be done with an external dependency (since > Shale presumes 1.4 or later anyway). Shale's own needs are very > modest, and would be adequately met by what is already built in.
Good point. This is also inline with what you wrote [1] three months ago:
[1] http://marc.theaimsgroup.com/?l=struts-dev&m=109900827818862&w=2
<quote> There are a lot of potential customers that have existing environments based on things like Log4J, and those folks would be really (and justifiably) irritated to be required to configure two logging systems. </quote>
In the last 3 months most of the log4j users have migrated to Mars and the remainder has switched to decaff. What a difference three months make!
> That being said, switching to either UGLI or JDK 1.4 logging would be > pointless if the objective is to banish JCL (reading Ceki on > commons-dev has been quite entertaining lately :-), since Shale still > depends on other packages that depend on JCL (currently Chain and > Digester, others will undoubtedly be added later). I don't see a > high likelihood that all of the packages that matter here would switch > away from JCL any time soon, and won't bother to re-implement any of > that stuff myself to eliminate dependencies.
Thank you Craig. I am glad to hear that you find my comments on commons-dev entertaining. I would have liked to see a reaction from you in response to my messages outlining the bugs found in JCL. Ooops, Sorry. Everybody knows that there are no bugs in JCL. Those LogConfigurationExceptions thrown by the JVM are due to outdated versions of the JDK or commons-logging or a combinations thereof. Ahh, those clumsy users. What part of use java.util.logging, not log4j, don't they understand?
> Personally, I plan to spend my time focusing on functionality instead > of on plumbing.
Me too, but preferably if the plumbing is controlled by my entourage. Welcome to the world of NIH.
On 2005-02-12 0:14:27, Craig McClanahan wrote:
> Although many people had encountered class loader related problems > with JCL < version 1.0.4, the bug fixes done there reduced the number > of failure scenarios to what has seemed like a pretty small number > (anything major remaining would have caused a firestorm on Struts > User, for example, because all Struts based apps would be affected). > Same thing on apps that run on the JSF reference implementation (which > also uses a subset of the same Commons jar files, and therefore > depends on JCL. I'm just not seeing or hearing about large numbers of > problems.
Absolutely. I am sure my analysis of JCL based on version 1.0.4 was somehow different than the version of JCL 1.0.4 that you are recommending. Maybe because my tests were done using JDK 1.3.1, 1.4.2 and 1.5.0. Is there a newer of the JDK I should have tried?
There is also the question of the thousands of surfers who arrive on the web pages "Think again before adopting the commons-logging API" [2] and "Taxonomy of class loader problems encountered when using Jakarta Commons Logging" [3].
[2] http://www.qos.ch/logging/thinkAgain.jsp [3] http://www.qos.ch/logging/classloader.jsp
The web-server logs show that they arrive there searching for:
commons.logging.LogConfigurationException more than one version of commons.logging org.apache.commons.logging.Log visible which is not allowed Class org.apache.commons.logging.impl.Log4JCategoryLog does not implement Log Log4JCategoryLog does not implement Log org.apache.commons.logging.LogFactory org.apache.commons.logging.impl.Log4JCategoryLog Log4j LogConfigurationException commons logging log4j exception Problem Using Log4J and Commons Logging with Struts exceptions while logging +tomcat
No doubt that such queries have nothing to do with JCL bugs users encounter. The only plausible explanation can be attributed to housewives searching for recipes for Borscht and Lemon Cake. After all, it's so easy to mistype "LogConfigurationException" instead of "Borscht".
> That being said, I don't use Log4J myself (other than the unit tests > that are in the JCL workspace), so it's entirely possible that there > are bugs that surface only in conjunction with Log4J. But even there, > I would have expected there to be rumblings among Log4J+Struts users > ... where are the mission critical problems these folks are having?
Absolutely. Where are they? I say ignore them as long as they don't coalesce into a political party and dominate both houses of Congress. The fact that the aforementioned bugs can be easily reproduced should not sway you either. The JVM is known to be an unreliable witness. The JVM can be bribed or intimidated. It can self-indulge or spin the story in a way serving its interests. There are also persistent rumors about drug abuse by certain JVMs. I won't even mention the sex-scandals involving JVMs in clusters.
> Be that as it may, the right answer to bugs in JCL is to fix JCL, not > start a crusade to banish it from the earth :-). If that requires > backwards-incompatible changes (as it appears that it might), so be it > -- IMHO class loaders are by far and away the most complicated thing > about Java (having been invoved in the development of the webapp class > loader inside Tomcat, I never want to see the insides of another one > :-). And that complexity can lead to corner cases that are broken. > If so, the next logical step is to find them and fix them. Ceki's > analysis will be tremendously helpful in that endeavor.
and it only took 3 short years to half-admit that there might be bugs in JCL. As usual, you are also right to point out that as long as JCL works with the logging API that matters, i.e. java.util.logging, corner cases, such as log4j compatibility, can be investigated at a later time. We can only agree with such a reasonable and wise approach. I'd suggest the year 2034 as a target date for fixing JCL. That'll give us a few years to play with a bug-free version of JCL before we all retire.
More seriously, I don't think that Apache Logging Services demands that JCL be banished. I am not aware of any steps in this direction taken by the Apache Logging Services project. Do you know something I don't?
However, it is true that we would like to see the bugs in JCL corrected as soon as possible. In the mean time, we are offering an alternative solution, called UGLI, which offers all of the functionality with none of JCL's bugs.
I suspect that the bugs in JCL will not be corrected before the original author, that means you, Craig, recognizes these bugs as major.
> Now, as to Shale in particular, we have a choice that we didn't in > Struts 1.0 - 1.2 ... since it assumes a JDK 1.4 platform, it would be > technically feasible to just use standard JDK logging. Indeed, if > Shale weren't depending on libraries already depending on JCL, that's > possibly what I would have done in the first place (although I must > confess that my fingers would have probably just typed "import > org.apache.commons.logging.Log" anyway, with no conscious thought :-).
JDK 1.4 logging would be my first choice as well. I mean if it's not in the JDK it can't be good, and if it's inside the JDK it must be sufficient.
> But I only use the logging inside Shale to debug Shale; JCL's > defaulting rules that pick the JDK logger for me (since I am on 1.4) > is plenty good enough for that, so I had no need to decide which > enterprise scale logging implementation I want to use. Or even to > configure the logging system I'm using, other than tweaking the debug > levels for the packages and classes I'm working on at the time.
> People building apps on top of Shale, on the other hand, might have > very specific reasons for preferring one logging implementation over > the other, and would still prefer to configure only a single logging > implementation. Keeping Shale based on JCL, instead of hard wiring it > to JDK logging, gives you that flexibility.
> Wouldn't converting Shale to UGLI do the same thing? Perhaps ... all > I've seen of UGLI is the javadocs, and it says it offers the same > benefits. OK, let's assume that is true But, it would mean adding > yet another third party dependency to complicate life for everyone, > and (at least in the short term, until *all* other JCL-using > dependencies were also switched) would lead to two log wrapping > abstractions to debug. When you also realize that both JSF > implementations people are likely to use (RI and MyFaces) also both > use JCL, "short term" starts seeming like it will last a very long > time.
Craig, I am surprised that a brilliant guy like you, who has single-handedly developed the initial versions of Tomcat 4, Struts, Digester, and last but not least, JCL, could not find the download link for UGLI. UGLI ships with log4j version 1.3alpha and later. The URL is
http://logging.apache.org/log4j/
I'll be happy to provide further details should the need arise.
> That doesn't sound like making the world a better place to me.
Of course not. Why add another dependency when you can roll out your own? Too bad your own thing breaks other products.
> So, the issue of switching just the Shale framework hasn't been > something I'd even thought about -- let alone trying to figure out > what I would switch to -- until today. From where I sit, it doesn't > seem like a wise choice.
Why would you want to use the logging system built by Apache? Who are these Apache guys anyway?
Ironically yours,
-- Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
