At 11:31 AM 3/25/2005 +0100, you 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. >
Thanks, Simon, for actually making a peep. We don't hear from the JCL guys (other than Yoav, who, I think, is more generally a Jakarta developer than JCL specifically). We want your input! The fact that we haven't gotten any here even after UGLI was announced (yes, I know there were discussions on the commons lists, but not here as far as I can recall) leads us (me) to the conclusion that it is business as usual with commons-logging (JCL has been broken from the beginning with plenty of complaints and no real fundamental fixes, so it should be understandable why we don't accept, on faith, that the JCL group has any real intention of addressing the issues). UGLI was (or should have been) a kick in the butt, and since I heard no yelps, it seemed obvious to me that the JCL group was uninterested. I've been wrong many times before and this may be no different. However, that's the perception. I'd like that *not* to be the perception. I'd like to work together to fix the problems. We just need some evidence that the JCL team is willing to do that. I'll take this email as part of that evidence. I'm hopeful!
>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. >
Good to hear!
>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.
Understandable. However, I'm surprised we haven't had at least one question on the Log4j-dev list about UGLI from the JCL group. Without a hint of interest (other than your apparent interest here), it is hard to believe that UGLI is being seriously considered. I think there is a large consensus that Log4j represents one of the very best options for J2EE logging in existence today (especially with new and improved features in Log4j-1.3alpha). The UGLI API is modeled after Log4j-1.3 while being agnostic to it and accommodating toward other logging API's such as JUL. With this in mind, I don't see how UGLI is not merely an option but a pretty solid front-runner? So, again, why zero questions to the group responsible for the API and implementations? Is it just such a perfectly understandable and well-designed product that no questions need be asked? If that were so, then there would be no question that UGLI is *the* prime candidate for the next version of JCL, and you would have said as much. There are, obviously, questions to be asked. Please ask them!
BTW, you might ask, "well, why doesn't the Log4j team introduce UGLI as the next JCL 2.0 to the JCL team"? Well, first we didn't know JCL 2.0 was really in the works (In any case, it is currently vaporware). Second, UGLI works and JCL doesn't. We don't have a particular interest in progressing JCL. That's not to say that we have a particular interest in stopping its progression but if JCL died because of apathy, I certainly wouldn't be mourning the loss. If JCL is destined to continue in a second version, then I think we have more of an interest in having input into how it works; to make sure it doesn't cause further headaches for users and continue to make Log4j look bad when it is usually commons-logging at fault (harsh? yes, True? yes). However, the JCL team must provide some evidence that it actually wants input and, to date, there is little evidence of this (other than this email). Ultimately, we can live quite happily with UGLI if we hear nothing from your end, because it works. Speak now or forever hold your peace.
> 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.
I imagine you are referring to http://www.qos.ch/logging/classloader.jsp . Ceki has taken input from several people to make sure his article reflects reality. I'm quite sure that he would take your input as well and apply it to make any changes to avoid any factual inaccuracy existing in the article. If factual inaccuracies actually exist, it means that no one in the JCL group was willing to correct those inaccuracies (I noticed just now that Robert Burrell Donkin pointed out typographical and grammatical errors). Until this happens, any accusation that Ceki is "plain wrong" about certain parts of the article will be treated as nothing more than FUD. You may perceive the article as an encouragement to "jump ship". In fact, it is a case study designed to be useful to Log4j users in understanding the errors Log4j users experience when using JCL as the logging interface. If by pointing out JCL's problems that convinces some current JCL users to "jump ship", then so be it. The errors are real and JCL is the cause. Why wouldn't one want to "jump ship"? To claim that this was the primary goal of the article is simply more FUD. Again, if there are inaccuracies, it would behoove you to point them out. I'm 100% confident that Ceki will correct them, assuming they are real. If he refused to do this, then you'd have a valid point.
> 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.
My tone is harsh because I've seen no evidence to date that the JCL team has any interest in fixing the issues or working with the Log4j team which has come up with a solid solution in UGLI. Please interpret this as "tough love". I'm going to be frank, though. I dislike your JCL product with a passion because it is consistently the source headaches. I'm not going to tip-toe around the issue. I will be diplomatic when it comes to finding a solution, but I am not going to hide my disgust with JCL as it currently exists and am, understandably (I hope), skeptical that anything but the status quo will prevail. I *want* to be proven wrong here! I want to find out that I've been gravely mistaken about JCL's intentions and that we will end up working together to find a solution. So when my "tone" is at issue, please remember the context and don't just apply it in an arbitrary way where you might say to yourself "Jake just doesn't want to work with us". That simply isn't the case. I think I can also safely say that I am speaking for Ceki as well.
> 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. >
"Discussion" would be appreciated. We haven't heard any from your end. No one is calling you "fools". But in order to have a "well balanced" discussion, there actually needs to be a discussion first. We don't expect you to just "jump" into UGLI, but since we created UGLI, it's logical that we are the ones to ask about it. You make it sound like you are going to decided amongst yourselves whether UGLI is an option or not and, if you decide so, then you *might* grace us with questions and whatnot. How about letting us help you understand what UGLI is and why it might be a good choice for you? And if you have concerns that something is not, "just so", then let us know and we can talk about making it "just so" to suit your needs? Like Log4j-1.3, UGLI has not been released in full yet, so there is time for modification.
>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 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. >
Nice to know.
>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.
>
>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.
>I haven't exactly thought this through much (Ceki, please point out if I am being naive here about the possibility of doing this with UGLI), but we could make JCL compatible with UGLI not by directly using the UGLI interfaces re-arranged into JCL's package and class space, but by JCL extending the UGLI interfaces, much as Log4j-1.3 does. Then JCL can keep any extensions it wants above and beyond UGLI while being compatible with UGLI. commons-logging.jar would ship with the UGLI API much as log4j.jar (or any other UGLI implementation) does. Then people can have their choice of API's with out any claims of an attempt at forking JCL (Remy). UGLI (or whatever name it ends up as) can be the official Apache logging API (with input welcome from ***everyone*** as to what constitutes the standard API) and JCL 2.0 can be a JCL 1.xx (hopefully) backwards-compatible API that also supports the standard (and fixes discovery problems, of course). This views JCL as a logging implementation, even if it is, itself, an interface. But, just like Log4j, the interface can be extended as desired by the JCL team to meet the needs of the various commons projects and JCL users. This provides freedom to different development teams to create the software they desire without the rancor of competing interfaces. Thoughts? JCL team? Log4j team? Anyone else?
>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, it would behoove you to discuss options with the Log4j team now rather than later. UGLI is slated to be released along with Log4j-1.3. If we are going to take up any ideas such as changing the name of UGLI or revising the interface, it's going to have to come before the 1.3 release (sometime in June/July????).
>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. >
We sincerely appreciate the input and hope for more of it in the future. Thanks Simon!
>Regards, > >Simon
Jake
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
