I'd be happy to be proven wrong, but isn't there one huge disadvantage of JUL - lack of per-webapp configuration? How would one webapp decide to redirect JUL to a file without affecting any other webapp in the same JVM? If this is indeed the case, JUL is a showstopper for any webapp that can't assume they are the only webapp in the JVM, which is just about everyone.
Don On Thu, Jun 18, 2009 at 9:28 PM, Emmanuel Bourg <ebo...@apache.org> wrote: > Ralph Goers a écrit : > > I disagree on both counts. Logging is critical to everything. Debugging >> problems can be quite difficult if logging isn't done well. Commons Logging >> isn't all that sophisticated IMO and using JUL as a facade isn't all that >> practical and just because it can be done doesn't mean it should be. The >> problem here is that JUL isn't really meant to be a facade and users picking >> up Commons Configuration would like Commons Configuration's logging to be >> integrated with their own. So having a "real" facade is of great benefit as >> the user will just configure their system for Commons Logging and be done >> with it. I do this with my applications and haven't yet had to configure a >> facade for Commons Logging as virtually nothing I am using in my environment >> uses it. Virtually everything I am picking up uses Commons Logging or SLF4J >> these days. >> > > And everything ends in log4j, where redirecting JUL requires just one line > in your configuration. > > Commons Logging and SLF4J made sense in a pre-Java 1.4 world. Today they > are just a hindrance inherited from the past. > > Btw I'll happily change my mind if someone demonstrates that the JUL > bridging isn't viable in production and causes unsolvable memory leaks or > horrible performances. > > Emmanuel Bourg > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
