Actually, Solr depends on Lucene :-) SLF4J doesn't have a "LogMessage" to propagate to the container since it's a simple thin facade to the logging kit you want to use. In the case of JUL which you're a fan of and what we all think should be the default implementation if you don't take steps to configure logging, any "LogMessage" (or whatever JUL calls it -- LogRecord?) would in fact be loaded by the system classloader. http://svn.slf4j.org/viewvc/slf4j/trunk/slf4j-jdk14/src/main/java/org/slf4j/impl/JDK14LoggerAdapter.java?revision=994&view=markup Here's the source implementation of SLF4J's JDK14 logger.
hossman wrote: > > : Yes, but why ship any libraries w/ Solr then? We should write > HTTPClient for > : ourselves, as well as all the other dependencies. Class loader hell is > at the > : very heart of Java and is just something we all deal with unless we go > to OSGi > : (I'm told, anyway, but I don't know enough about it) or build everything > : ourselves. > > we do in fact depend on third party libraries for soemthings, and yes it's > possible that those libraries might be version incompatible with libraries > already in use by the containing app (regardless of whether it's a servlet > container or something else) -- i have sweated over every one of those > decisions in the past because of potential conflicts. > > BUT! ... There are two (really) three key differneces here... > > 1) we currently have no dependencies (that i know of) that are "core" > dependencies -- ie: Solr won't work at all if there is a conflict. All of > our external dependencies right now are things that if there is a > conflict, that just means you may not be able to use an optional feature > (ie: remote ContentStreams if commons-http has a conflict, the > ShowFileHandler if commons-io has a conlfict, the PhoneticFilter if > commons-codec has a conflict) > > 2) Almost all of our existing use cases of third party code are very > isolated such that they are very unlikely to come into play when dealing > with parent context classloaders -- in an enviornment where logging is > centrally managed a "LogMessage" object is very likely > to get propogated up the tree out of the Solr context to the point where > class compatibility becomes an issue ... we don't exactly pass instances > of HttpClient arround in ways that the ServletContainer is likely to > encounter problems if they differ (multiple versions of a class can be > loaded the same JVM, you just don't ever want to "cross the streams" as > the ghost bsters use to say) > > > (The third differnce I see is in the idea of adding a depndency that > doesn't actually add a feature -- this is a philosophical argument, people > could say that "easier third party logging abstractin is a feature", but i > disagree, and am willing to ignore that issue, but i mention it for > completeness since I (and Erik) have brought it up before) > > > -Hoss > > > -- View this message in context: http://www.nabble.com/Solr-Logging-tp16836646p17068918.html Sent from the Solr - Dev mailing list archive at Nabble.com.
