Hola, I have not participated in this thread at all (lack of opinion due to lack of significant experience/knowledge in this area), though I've read all messages. But how about this idea:
- Let people change from JUL to whatever - Observe solr-user reactions to the change after the 1.3 release - If there are objections, problems, etc. consider going back to JUL or improving logging in some new direction - If all is cool, leave things as is and be happy It's just software, after all - it's not like changing things will prevent us from undoing them in the future. Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch ----- Original Message ---- > From: Chris Hostetter <[EMAIL PROTECTED]> > To: Solr Dev <solr-dev@lucene.apache.org> > Sent: Saturday, May 3, 2008 8:31:01 AM > Subject: Re: Solr Logging > > > FYI: I'm going to commit a minor list taboo and comment in a thread I'm > not caught up on -- I wrote this on the plane based on some thoughts I had > last night and this morning, and even though i don't have time to catch up > with this thread, I wanted to put this information out there since i > probably won't be online again for a few days... > > --- > > I was reading some interesting stuff about "controversy" in an OSS project > called Pidgin. Based on what I read, the issue there is *vastly* > different then the question of wether or not we should change the logging > API used by Solr, but some of the comments I read did cause me to do a > little "Soul Searching" on the topic of Developers and the user > communities they (for lack of a better term) "serve". I started wondering > if I was being overly dogmatic about logging and not respecting the "will > of the community". I started to ask my self: what would it take for me to > change my opinion on this issue from a "-1" to a "0" or "+1" ? > > The various objections I have to switching away from JUL (aka: JDK > Logging) to anything else can be boil down to three main "themes" ... > > 1) JUL is "the right" API. > > 2) Making a major change like this could break logging for users that > want to use JUL implementations as it was intended. > > 3) Reliance on a third party library for something as core as logging > could expose us to class incompatibility issues. > > #1, although something I firmly believe, is admittedly subjective. If > doing "the right thing" isn't what the community as a whole wants to do, > then I just have to respectfully disagree with the community. This point > alone basically garuntees that I'll never vote "+1" to switching away from > JUL. > > #2 and #3 are admittedly hypothetical situations, but if either did arrise > they would be *massive* failures of the Solr project, so we need to be > dilligent to protect against those possibilities. > > If a large subset of the community is in favor of moving away from JUL > towards some alternative (and I'm not sure that's true), and community > members are willing to extensive testing against the possibility of these > problems (using a large set of different Servlet Containers), then I would > be willing to withdraw my objection (ie: vote "0") ... I won't stop > arguing that JUL is "the one true logging API" but I won't stand in the > way of "progress" either. > > > The caveat to this is that even if a good alternative logging > "abstraction" exists, and we test it extensively, and have a high > confidence that it will play nicely with JUL implementations, I would > strongly suggest that we: > a) Use it only if it's "default" behavior can be set to defer to the > configured JUL LogManager (This is basicly "mandatory" in my > opinion, since otherwise Solr won't be backwards compatible) > b) Note in our documentation that Solr's usage of this abstraction is > "experimental" and may be changed in future releases (If we > encounter problems with it or decide there is some *better* > abstraction) and that configuring a JUL LogManager is the > recommended way to recieve logging messages from Solr. > > > > -Hoss > >
