I definitely think that most of log4j2 should be POJOs (plain old java objects). If we need to have an overarching component framework like log4j 1.3 had with its Component, Scheduler and the like, then we should not reinvent the wheel. However, I don't want to prejudge that we need one and I don't want to prejudge that it would be OSGi if we did.
Yes, I definitely agree that reinventing the wheel is bad. If there is _some_ way that a virtual 'log4j20-core.jar' would not depend on anything at all, then that would be great. I'm thinking the only thing that might prevent that is if some 'scheduler' type component that manages rolling file appenders needed to be setup. This goes to the tricky balancing act of packaging and dependency. Too many sets of log4j20 packages to choose from might simply confuse people, so we'll need to be careful about how we strike the balance between dependencies/size etc.
I reread http://www.martinfowler.com/articles/injection.html to refresh myself of IoC. I liked his emphasis on "Separating Configuration from Use". I'm thinking that designing for concurrency would make dependency injection by constructor the natural IoC pattern (since concurrency design would favor immutable classes), however it would be best if we have a mechanism to play well with other approaches. The approach that I'd suggest is working out the "use" classes designing for concurrency and all other goodness and when there is enough to make a testbed start experimenting how configuration of those classes would be done with JMX, Spring, et al.
Yes, some fundamental look at where exactly the synchronization points in a virtual design is probably worth discussing first before we get down to the finer points of how it fits into an IoC type setup. I think this is what you mean by seeing some example code in action, which doesn't necessarily translate to _actual_ code committed to a log4j20 trunk?
The java.util.logging API has been part of the JDK since 1.4. log4j 1.2 offers a much richer set of appenders, layouts and configuration options than available for java.util.logging. I think it would be desirable that log4j 2 be designed so that it is trivial to use the log4j 2 appender set with the java.util.logging API for the users who are satisfied with that API. Current approaches to bridge the log4j and java.util.logging world require constructing a new o.a.l.spi.LoggingEvent from info extracted from a java.util.logging.LogRecord. I'd hope the log4j 2.0 design could accomplish the same goal without having to do the brute-force copying.
That is quite a worthy goal, but only time will tell how practical that might be. I'm not sure we should restrict the design of anything to accommodate this, but certainly have it in the back of our minds.
Paul --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
