Rahul Akolkar wrote: > On Fri, Jun 19, 2009 at 11:07 AM, Emmanuel Bourg<ebo...@apache.org> wrote: >> Ralph Goers a écrit : >> > <snip/> >> >>> 2. In all the various logging discussions that have taken place on this >>> list in the last few months, many initiated by me, the concensus seems >>> to be that commons logging is the logging framework that should be used >>> by commons projects. Although not my preference I will abide by that. >> >> The consensus is nobody wants to engage in a heated discussion about >> logging ever again. We have wasted too much time on this topic. > <snap/> > > Sigh, indeed. > > >> So the default >> choice wins, that's Commons Logging. But that choice is just inherited >> from the Java 1.3 compatibility era. >> > <snip/>
it is as Don said, in a JEE environment JUL is really the worst choice. We have some global players as customers and they have all very specific requirements regarding logging to ensure their monitoring process of the life systems. This is in the range of using a very special format up to using their logger framework. If you deliver a EAR or WAR you cannot control the format of JUL at all, since a JUL-formatter must be available at the server path. Additionally it is not possible to provide an alternate implementation. I am quite sure that cc2 with JUL would force us to create an internal fork. JULI for Tomcat only works *because* they are the server. > And two principles: > 1. Minimal disruption. Commons is widely used, such that for released > components, anything that causes any amount of disruption to users is > no good. > > 2. Communal responsibility. Commons libraries tend to be used in > bunches. Its good when we are consistent in logging. Historically, > most Commons libraries have used CL. If we really want to think about a next generation CL and agree that the approach SLF4J has taken is te right one, then I'd rather move CL 1.x into maintenance mode and use SLF4J directly instead of reinventing the wheel. However, that move should be done then for all commons components because of reason 2. - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
