Let me clarify my stance here. JDK logging (aka JUL) is a logging
API, though it is not a full-featured logging implementation. One
would of course want some fuller featured logging APIs, but it is a
separation (of concerns) for Solr in a sense. Solr logs to JUL, and
the deployer of Solr is responsible for plugging in a different
logging implementation if desired.
It is a shame that log4j does not include an adapter (that I'm aware
of) for JUL - it should. If it did then this would be a non-issue
and we'd just do the one step it takes to wire JUL to log4j (a system
property on the command-line).
I fully support the addition of the trivial classes (what are we
talking, 10 lines of code or so?!) it takes to adapt JUL to other
logging systems being added to Solr itself until these logging
systems have their own adapters built-in.
Erik
On Apr 23, 2008, at 2:42 AM, Thomas Peuss wrote:
Erik Hatcher wrote:
I'm also opposed (sorry Grant) to tossing in a 3rd party library
for logging when the built-in logging facility is sufficient,
configurable, and adaptable already.
I must say I never liked JDK logging because it feels like a step
back when you are used to log4j.
So from my perspective:
* Solr is a software you mostly run on servers. So log rotation and
sending emails on errors is a must. Nothing of that is provided by
the JDK logging implementation (or does not work correctly as
someone else has stated).
* JDK logging configuration is only on JVM level. When you use many
Solr instances in one JVM (we have one per customer) and want
several different log destinations that is not possible. I want
logs per customer - that is currently not possible.
I would like to see SL4J based logging in Solr. commons-logging is
no alternative. It is meant for libraries because "commons-logging
does not attempt to initialize or terminate the underlying logging
implementation that is used at runtime; that is the responsibility
of the application".
CU
Thomas
