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
