On Feb 10, 2012, at 15:08, 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. Let's make it better then. Pool2 can drive the requirements and we'll eat our own dog food. Gary >> >> 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
