On Feb 12, 2010, at 8:29 AM, [email protected] wrote: > https://issues.apache.org/bugzilla/show_bug.cgi?id=48704 > > --- Comment #7 from Ceki Gulcu <[email protected]> 2010-02-12 14:29:36 UTC --- > (In reply to comment #6) >> I have not reviewed the logback implementation, but there is nothing that >> indicates that implementing the "prudent" mode in log4j would not be >> possible. > > Prudent mode could be implemented in log4j. It would just take a few days of > work.
Will spin that off into another thread. > >> Apache log4j and QoS.ch's logback have a shared heritage, but have divergent >> licenses, communities and governance. Statements from one fork about the >> other >> should be considered in that light. > > Arnold, speaking of governance, when do you plan to put your seat as > chairman of the Apache Logging project for elections? Five years > without elections is not exactly the Apache way, is it? For background for those who are new to this topic. From http://www.apache.org/foundation/how-it-works.html#pmc-chair: > > The Chair of a Project Management Committee (PMC) is appointed by the Board > from the PMC Members. The PMC as a whole is the entity that controls and > leads the project. The Chair is the interface between the Board and the > Project. Except in extraordinary circumstances, the PMC chair should have no more control over the direction of the project than any other PMC member. The PMC chair is required to report to the board quarterly or as directed by the board and is responsible for managing SVN rights. Nothing prevents anyone else from sending an email to [email protected] if the PMC chair is out of line. Managing SVN rights should be in response to a PMC vote. I am due to file another quarterly board report and will mention your concerns. You are also free to petition the ASF Board. > You previously > stated that since the advent of java.util.logging there was no longer > any need for log4j. It is my understanding that your vision for the > future of log4j is to see it vegetate and die. Or am I misquoting you > in some way? > Yes. I believe the thread that you are thinking about is http://marc.info/?l=log4j-dev&m=122841935827332&w=2. You were arguing that log4j 1.2 should make a significant API change (changing Logger.info(Object) to Logger.info(String) et al) to enable convergence to a logging standard (SLF4J). My statement was to the effect that the API standardization war was won by java.util.logging and isn't going to be deprecated in favor of SLF4J if only log4j would change its API to align with SLF4J. I think that log4j 2.0 should clearly separate the logging backend from the API and that the backend be capable with working with multiple API's including java.util.Logging, org.apache.log4j.Logger and SLF4J. Relevant JIRA issues: http://issues.apache.org/jira/browse/LOG4J2-5 http://issues.apache.org/jira/browse/LOG4J2-6 http://issues.apache.org/jira/browse/LOG4J2-11 http://issues.apache.org/jira/browse/LOG4J2-12 http://issues.apache.org/jira/browse/LOG4J2-27 I do believe that incremental fixes and enhancements to log4j 1.2 are worthwhile for the established community. While I'm not making as many commits as I would like, I'm making a whole lot more than someone who wants log4j to vegetate and die. Due to the large number of implementation details exposed in the classes, it is very difficult to make substantial changes to log4j 1.2 without compatibility issues. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
