On Feb 19, 2010, at 8:22 PM, Curt Arnold wrote: > > On Feb 19, 2010, at 5:42 PM, Christian Grobmeier wrote: >> >> However - we (all who are interested in continuing log4j) need to >> discuss other options. Using SLF4J as native interface or not might be >> the next discussion. Looking at the current code we currently have is >> the next one. >> > > Before jumping into implementation issues, I think it would be best to try to > collect as many potential requirements, design principles, etc, so we know > what things are important to us and to our potential users before starting to > make design decisions. There are several usable logging frameworks out > there, it would be good to know what issues are bothersome, limiting, > irritating, desirable, etc. We may need to sacrifice one feature for > another, but it would be best to know that we are making trade-offs. > > I requested a log4j 2.0 JIRA (https://issues.apache.org/jira/browse/LOG4J2) > several years ago to serve as a place to collect that type of info. I've > entered much of the stuff there, but none of them should be taken as mandates > or directives. They are ideas. I thought they were good at the time. I > would love to see other people throw in their ideas and pains, help refine > others, etc. At some point, we can start to narrow down which are required, > desirable, marginal or impractical. > > Probably would be good to invite the other ASF projects that have a logging > dependency to post their issues, concerns or wishes. > > Supporting SLF4J as an interface is already logged as a design issue > (http://issues.apache.org/jira/browse/LOG4J2-27). However, I think it is > strongly desirable to make much of log4j 2.0's back-end classes independent > of the logging API which was the gist of LOG4J2-5.
I agree with this. I also think the interface should be in a separate API jar. If we want to make the implementation pluggable that is fine by me as well. > > In my mind, what defines log4j 2.0 are LOG4J2-3 (fine grained locking) and > LOG4J2-7 (designed for JDK 5+) with LOG4J2-4 being likely the next most > significant. Actually, I'd like to target Java 6 since it has better support for annotations. Of course, the annotation support could probably be provided separately. > > Experimenting with some of the core issues to clarify ideas is probably > valuable. The stuff I did in the sandbox was to explore LOG4J2-13 (distinct > extract/render phases) and LOG4J2-5 (backend independence from API). > > Another area worthy of exploration is LOG4J2-9, basically designing log4j 2.0 > to be configurable from multiple configuration frameworks. > Yes, using an SPI and allowing the configuration to be pluggable would be good but can get very tricky, especially since Log4j needs to support dynamic reconfiguration. I've opened a few more Jira issues regarding support for annotations and for supporting Message objects. I've implemented this for Logback and would like to see this be a fundamental part of Log4j 2.0. BTW - logging.apache.org and http://logging.apache.org/log4j/2.0/index.html don't seem to have a link to Jira. Ralph --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
