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. 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. 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. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
