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.
