I am very glad to see that work is being undertaken to address JCLs problems. Your work on test cases checking correct garbage collection of class loaders referenced by static variables also shows promise.
More below.
At 11:31 AM 3/25/2005, Simon Kitching wrote:
Hi All,
I�m a commons committer and have been involved in the recent commons-logging work going on there. I thought you might be interested in a view of this topic from "the other side of the fence". Note, however, that I am speaking only for myself in the rest of the email.
It is accepted that people have problems using commons-logging, and generally accepted (though not yet 100% proved) that fixing these problems will require significant change to the existing commons-logging implementation (though *hopefully not* the user API). A significant amount of work is going on right now on the commons lists to investigate the issues and look at possible solutions.
Indeed, and we all very interested to learn about the results.
Simply adopting the UGLI approach is one possibility. However it is becoming clear that the issues surrounding logging in j2ee-style apps are quite complicated; before adopting a radically different solution we all need to be sure we understand all the issues, and don�t leap from one incorrect solution to another. Ceki�s very confrontational tone hasn�t helped the case; while I respect Ceci�s technical ability very much some of the information in articles written by him about the existing commons-logging is just plain wrong, and intended to persuade users to jump ship rather than provide a fair evaluation. We (jcl maintainers) need to thoroughly understand jcl, ugli and all the user requirements before making a final choice - and this is what is in progress right now. Jacob�s tone has been similar. Guys: there *isn�t* any ego or "not invented here" reason for failing to jump immediately to using UGLI; it�s that we need to be sure UGLI is the right solution first and no amount of yelling at us or calling us fools will make us decide to make that leap without doing the necessary research first. Well-balanced and reasonable discussion, on the other hand, is very much appreciated.
No ones likes to be told that the software they are distributing causes problems. These are being reported on a regular basis for over 3 years now. Unfortunately, it seems to me that only recently has the attitude started to change and legitimacy of the aforementioned problems recognized. As log4j developers, we can only applaud and encourage this change of heart. Simon, please keep up the good work.
At this stage, perhaps we can also hope that jakarta-commons at least consider alternatives to JCL. On our side, as the chairman of the Apache Logging Services project, I can pledge that our project will not apply any form of pressure on jakarta-commons, except through regular discussion. We recognize that jakarta-commons has the right to choose the solution that best fit its needs. Freedom of choice is one of the guiding principles of the foundation.
The reason for the existence of commons-logging is that the commons projects need a logging API that they can use. I�m personally neutral on whether that API should be maintained via a project under the apache-jakarta-commons umbrella or the apache-logging umbrella. Having it under commons does, however, emphasise its platform-neutral status better than having it managed by the same team responsible for providing one of the implementations it wraps. Whether it is in jcl�s best interests for the owing project to be specialist (apache-logging) or generalist (commons) is up for debate; both have pros and cons.
I see. Do you think it would be better if such a project was outside both Logging Services and Jakarta Commons? Start afresh with a new project and a new name, perhaps even outside Apache? In your opinion, would that ensure greater neutrality, or perhaps perception of neutrality?
I don�t think anyone working on commons-logging really cares about "branding" or "market share". Commons-logging exists because it solves a problem that the other commons projects faced: the commons libraries need to log stuff to help users diagnose issues, but can�t bind to a specific logging implementation because the code using the library may want to use a different implementation. If others find it useful in their libraries (or even non-library code) then that�s nice but JCL is not trying to take over the world, so naming isn�t that important, nor is which umbrella project the code lives under.
+1
Note, by the way, that commons-logging existed well before log4j became an apache project, and a long time before the "apache logging" umbrella project was created. You might also note that I was providing (minor) patches to log4j well before I got involved with commons.
Not that it matters, but it should be noted that the earliest file in logging-log4j CVS repository [1] dates back to December 2000 whereas the earliest file the commons-logging CVS repository [2] dates back to August 2001. Thus, i find the claim about commons-logging predating log4j rather surprising.
[1] http://cvs.apache.org/viewcvs.cgi/logging-log4j/ [2] http://cvs.apache.org/viewcvs.cgi/jakarta-commons/logging/
You are however quite right in mentioning your past contributions to log4j. I hope there will be more from where that came from. :-)
Regarding "yet another logging interace", I don�t think this is an issue. There are no major problems with the existing API for use by user code as far as I am aware. There are two proposed extensions to this interface (i18n, and allowing message interpolation of form "Error {0} occurred in {1}"). However these would seem to fit nicely as extensions to the existing api rather than replacements of it. There will almost certainly be a change to the API used when writing adaptors from JCL to concrete logging implementations, but that�s no big deal. The only issue is that if jcl moves, then the package name "org.apache.commons.logging" will need to change, causing wide-spread (though trivial) changes to code using JCL.
Sounds reasonable.
I would think that consensus on what will happen to JCL is likely to be reached within the next 3 months, given the progress made over the last month or two.
Again, I would like to restate that all of this is my personal view only, as one (but not the most important) of the commons committers working on commons-logging.
Thanks for sharing your opinions with us. As an active committer, I believe that your opinion will carry considerable amount of weight in the jakarta commons side of the fence.
Regards,
Simon
-- 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]
