>If you mean "i have to write code to create a logging implementation" then >yes ... that is true ... someone, somewhere, has to write an ?implementation of the JDK Logging API in order for you to use that >implentation -- and if you don't like any of the other implentations out >there, then you might have to write your own. :)
Correct, but there are a number of already existing frameworks out there that already do all of this for you, most of them even let you pick your underlying logger so if you've already written a fancy JUL "rotating, parsing and email me when things get bad" handler then you can still use it. I do agree that commons logging is a bit 'off' to say the least and many projects including Jetty6 are moving to SLF4j. Also, if solr as an application is using Solrj under the hood for federation it would seem that solr is already using 2 different logging mechanisms. For consistency sake we should consolidate on one single configuration mechanism. It would seem that one of the following would make sense: * change solr4j to be JUL based. I think you already said would be bad since it's a library and should not impose logging choices * change solr to be commons logging based. I agree it's a bit awkward with all the classloading but it is a ~standard to a large extent * change both to be 'framework XYZ' based. Fyi: slf4j already has a creepy little migrator tool that might be of use. In the end, I already have my shim that does the necessary translation but it's nowhere near a general solution that the log4j community could benefit from. As long as things are consistent and easy to configure to get standard logging functionality I'm happy. - will Not to pimp out slf4j too much but the base implementation is only ~22k or about the same size as commons-csv which is also a dependency.
