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.
The thing is, as Ryan has pointed out, many of us are not using Solr
necessarily in a webapp, or at least not standalone as just solr.war
and would like to have more control of logging w/o having to write a
bunch of code to do it, when the answer is simply to include one 16k
jar and change something like 100 lines of non-critical path code and
we can have our choice of loggers, including JUL.
One thing I am wondering, has anyone benchmarked the loggers? I'd be
curious if there is any performance benefit to any one over another.
On May 1, 2008, at 8:44 PM, Chris Hostetter wrote:
It's not just a question of API compatibility, it's a question of
*class*
compatibility (ie: byte code)
Even if the public APIs are consistent, it's very easy to get into
"classloader hell" when a webapp has one version of a class loaded
(even
if it's a private class) while the servlet container has another
version
loaded -- especially in the case where webapps will likely be passing
these objects up to code running in the Servlet Container context (for
example: the "default" case of a centrally configured logging)
This, by definition, cannot happen with JUL, because there is only one
version of the j.u.l.* class files loaded by the JVM at anyone time.
: Hmm. This is probably fixable doing either of these two (both are
easy):
: 1. update the SLF4J in Jetty
: 2. at deploy time either remove slf4j from the war, or configure
Jetty not
: to use it (JBoss has that latter feature which is quite nice)
:
: This is also a scenario that could play out with JUL, it's just
embedded
: with the JDK. Sun just hasn't updated it yet (if they did I am
unaware;
: simple searches suggest not).
:
: Any way, I think that logging APIs stabilize really fast by
necessity --
: nobody wants a fast changing logging API. I'd be really surprised
to hear
: of this sort of thing from any of the usual suspects going
forward. I am
: referring to the API where frameworks log to, not other parts
which apps
: tend not to write to.
-Hoss
--------------------------
Grant Ingersoll
Lucene Helpful Hints:
http://wiki.apache.org/lucene-java/BasicsOfPerformance
http://wiki.apache.org/lucene-java/LuceneFAQ
