On the performance side, I don't expect to see any different performance than what we have today, since checking if infoStream != null should be similar to logger.isLoggable (or the equivalent methods from SLF4J).
I'll look at SLF4J, open an issue and work out a patch. On Sat, Dec 6, 2008 at 1:22 PM, Grant Ingersoll <[EMAIL PROTECTED]> wrote: > > On Dec 5, 2008, at 11:36 PM, Shai Erera wrote: > > >> What do you have against JUL? I've used it and in my company (which is >> quite a large one btw) we've moved to JUL just because it's so easy to >> configure, comes already with the JDK and very intuitive. Perhaps it has >> some shortcomings which I'm not aware of, and I hope you can point me at >> them. >> > > See http://lucene.markmail.org/message/3t2qwbf7cc7wtx6h?q=Solr+logging (or > http://grantingersoll.com/2008/04/25/logging-frameworks-considered-harmful/ > for > my rant on it!) Frankly, I could live a quite happy life if I never had to > think about logging frameworks again! > > As for JUL, the bottom line for me is (and perhaps I'm wrong): It doesn't > play nice with others (show me a system today that uses open source projects > which doesn't have at least 2 diff. logging frameworks) and it usually > requires coding where other implementations don't. My impression of JUL is > that the designers wanted Log4j, but somehow they felt they had to come up > with something "original", and in turn arrived at this thing that is the > lowest common denominator. But, like I said, it's a religious debate, eh? > ;-) > > As for logging, you and Jason make good points. I guess the first thing to > do would be to submit a patch that adds SLF4J instead of infoStream and then > we can test performance. It still amazing, to me, however, that Lucene has > made it this long with all but rudimentary logging and only during indexing. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
