Hi Ralph, log4j2 looks really promising, I'll join the logging ML.
And nice to see fluido-skin in action :P -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Fri, Feb 10, 2012 at 9:34 PM, Ralph Goers <ralph.go...@dslextreme.com> wrote: > The better thing to do would be to point you to http://logback.qos.ch or > http://people.apache.org/~rgoers/log4j2/. Compare the features in either of > those against JUL. > > When building a framework you can't look at logging in isolation. Nobody > wants to configure JUL and Logback and Log4j, etc. > > Ralph > > On Feb 10, 2012, at 12:14 PM, Simone Tripodi wrote: > >> Hi Ralph, >> >> just for a matter of curiosity and filling my lacks of knowledge, can >> you point me please to some doc about the lacks of j.u.l. ? >> >> Many thanks in advance, all the best! >> -Simo >> >> http://people.apache.org/~simonetripodi/ >> http://simonetripodi.livejournal.com/ >> http://twitter.com/simonetripodi >> http://www.99soft.org/ >> >> >> >> On Fri, Feb 10, 2012 at 9:07 PM, Ralph Goers <ralph.go...@dslextreme.com> >> wrote: >>> >>> On Feb 10, 2012, at 7:02 AM, Mark Thomas wrote: >>> >>>>> >>>> >>>> Yeah, that isn't going to work. I really do wish java.util.logging had >>>> been designed with JavaEE in mind. Clearly it wasn't. We tried fixing >>>> this in Tomcat but even with JULI the APIs just aren't available to do >>>> this. You could do JVM specific hacks but they will break just as soon >>>> as the JVM vendor changes their internal API (as they are perfectly >>>> entitled to do). In the end, Tomcat categorized this problem as WONTFIX. >>> >>> Sorry, JUL wasn't designed with anything in mind as far as I can tell. It >>> sucks as a facade and the implementation is barely adequate. I've delayed >>> creating the bridge from JUL to Log4j 2 primarily because all the ways to >>> do it are bad. >>> >>>> >>>> With this in mind, commons-logging is a better choice as it should be >>>> possible to have an entirely contained logging setup within the >>>> application and a properly written container shouldn't interfere with >>>> this. Commons-logging is also relatively simple to redirect to something >>>> else. >>> >>> That is the primary reason to use Commons Logging, IMO. Unfortunately, the >>> API is pretty minimal. >>>> >>>> Given the discussion so far has been around commons-logging or >>>> java.util.logging, I think these two are the front runners. I can live >>>> with either but I have a very narrow focus - i.e. what can i get working >>>> easily with Tomcat's packaged renamed version of pool2. >>> >>> I'm not sure why you'd rule out SLF4J. Although it isn't perfect, as a >>> facade it works pretty well. >>> >>>> >>>> Taking a wider view, commons-logging is probably the better choice as >>>> although it adds a dependency, it is easier for folks to integrate with >>>> their logging framework of choice. >>>> >>> >>> Yes, it is a much better choice than JUL just because of that. >>> >>> Ralph >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
