My main point is philosophical - adding another dependency just for
logging seems so wrong.
Pragmatically - I give up.... I won't block an overhaul to Solr's
logging .... I'll just quietly cringe.
Erik
On Apr 29, 2008, at 10:25 AM, David Smiley @MITRE.org wrote:
Whenever I see a project with some home-grown LogManager that provides
loggers, I am always mildly disgusted no matter how simple it is (no
disrespect to you, that is my opinion). I believe use of SLF4J
will meet
common goals. Solr should log to SLFJ4J (slf4j-api.jar) and then
out-of-the-box ship the slf4j-jdk14.jar (or not but Eric Hatcher
seems to be
a fan; but it's really not that important any way). Then, if
someone (like
me :-) would like to configure logging with log4j then I am easily
empowered
to do so by removing that jar and adding slf4j-log4j.jar. What I
like about
sfl4j is that it is the most logging agnostic of logging apis for
java. In
theory, JUL is an agnostic choice but for a variety of reasons that
have
already been discussed on this list, it isn't.
~ David Smiley
Henrib wrote:
I've been fiddling with java.util.logging from jul-to-log4j bridge
to the
idea of implementing a LogManager.
In the latter case there are a lot of deployability caveats, in
particular
the fact that there is no common way of configuring them between
servlet
containers. Trying to tame Websphere on this respect for instance
seems
like a difficult battle.
In the former case, the jul-to-log4j bridge suffers - in some
environment
- from the fact that the LogManager & al may have security
restrictions
that wont allow manipulating some Logger properties.
But in all cases, I miss the log4j deployability that does not
require
anything but the fact that some classes exist in the jar/war (ie,
no need
to set something globally in the servlet container or use a JVM wide
property).
The only solution that I've been able to find is to have Solr
cooperate
and implement its "own" org.apache.solr.Logger "shim" that behaves
like a
local LogManager and trigger the implementation switch by using a
log4j
adapter class; if the adapter class is present (aka loadable), the
Loggers
are anonymous (j.u.l.Logger.getAnonymousLogger) with one handler that
transforms the LogRecord into log4j events. Otherwise, if that
class is
not present, it just reverts to usual j.u.l logging.
The only code change is to use
org.apache.solr.logging.Logger.getLogger(...) instead of
java.util.logging.Logger.getLogger(...) (37 occurences if I'm not
mistaken). There are also 4 new files, only one being dependant on
log4j
and one class whose presence in the jar/classpath determines the
log4j
redirection.
In general terms, it means a "casual logging" library/application
like
Solr can use JDK logging (and no external/log4j dependency) and be
made
log4j "friendly" at a cost of 3 classes and a convention. I'm not
sure
this is a valid bug/rfe to post and I don't know how to package
this as a
patch for general consumption (log4j dependency, build.xml & al).
Anyway,
the "raw" material is attached here for review & comments.
http://www.nabble.com/file/p16825364/logging.tar.gz logging.tar.gz
Henri
--
View this message in context: http://www.nabble.com/logging-through-
log4j-tp13747253p16961288.html
Sent from the Solr - Dev mailing list archive at Nabble.com.
