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. hossman wrote: > > > : 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. > > Unless that container already uses SLF4J (ahem: jetty) and the version > used by the container is differnet then the version used by the war ... in > which case class version incompatibilities could arrise. > > With JUL, there is never any possiblity of a problem like this. > > > > -Hoss > > > And in another related thread... hossman wrote: > > that's exactly my point: Any application that loads arbitrary code > specified at runtime (and a servlet container fits this definition) need > to be able to deal with possibility that that code will use JUL, so they > have to deal with it -- servlet containers that don't make it easy to > configure how you want them to deal with that aren't very good servlet > containers (in my opinion). If you don't like the way the servlet > container you are using deals with JUL messages, don't blame the code > using JUL, blame the servlet container. > I agree that one metric of a container's quality is how well it configures JUL. And even more so, it's ability to configure the logging frameworks that are actually widely used ;-) I don't think I'm "blame"ing Solr for using JUL so much that I'm saying that the issue of how well the container configures JUL could be averted by using SLF4J. As I told Eric, it's not you and the other Solr committers' fault that the situation is the way it is. The logging situation in Java is a mess. Sun is to blame for that. As a pragmatic matter, there is no JUL to Log4j adapter out there and so this is a thorn in my side; otherwise I might not care so much. I guess I'll shut up for now; we seem to have gone at it for awhile and I'm not sure what more there is to say on either party. ~ David -- View this message in context: http://www.nabble.com/Solr-Logging-tp16836646p16973746.html Sent from the Solr - Dev mailing list archive at Nabble.com.
