hossman wrote: > > ... > There may be servlet containers that don't do a particularly good job of > dealing with JUL (aka: JDK logging) but that is their deficiency, not > Solr's. >
That is a convincing argument, admittedly. But by using SLF4J, Solr won't alienate users using such containers (like me, using JBoss 3.x), ANY container should be fine based on the way SLF4J works. hossman wrote: > > Any other logging framework, abstraction, or intermediate API we might > decide to use introduces a dependency which *may* have classpath issues, > *may* have class version conflict issues (if the servlet container already > uses differnet version), or *may* screw with the ability of servlet > containers to manage logging configuration. (i won't name names, but i've > seen some logging "bridges" that muck with handler registrations in the > LogManager API to the point that they break otherwise fully functional > Context aware LogManagers with nice configurations just be being included > in a war file) > > It really just doesn't seem worth it to me. > I suspect your concerns about "other logging frameworks" & bridges is related to JCL. If you had SLF4J in mind then please do "name names". Respectfully, David Smiley -- View this message in context: http://www.nabble.com/Solr-Logging-tp16836646p16972876.html Sent from the Solr - Dev mailing list archive at Nabble.com.
