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
