On Apr 15, 2007, at 9:34 PM, Paul Smith wrote:
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.
Any dependency of a log4j 2.0 core on anything outside of Java SE 5
would need to be carefully reviewed and clearly justified. Might
also want to limit log4j 2.0 core to one of the Java ME profiles.
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?
I'm hoping that the development path that I've outlines for the
pattern-layout repackaging would result in something that could form
the basis of log4j 2.0, but it is just an experiment and there is no
guarantee that the experiment will be successful or that the PMC
would adopt for log4j 2.0 or that there would be a log4j 2.0 at all.
Any other committer that wants to experiment on something in the
sandbox is free to do so.
I think that use fits within the description of project sandboxes in
the Apache Labs bylaws (http://labs.apache.org/bylaws.html). I think
it is highly beneficial that even the exploratory code is done in
public view, false starts and all.
For the initial work around layouts, I'm believe that layouts should
not depend on any external synchronization and should have no or
minimal need for internal synchronization. The configuration classes
around appenders would require synchronization, but the actual
working appender classes should not depend on any external
synchronization. Many classes of appenders will need to be
synchronized at some point on a shared resource (a file for example),
but the framework should allow fully concurrent appenders (for
example, an appender that simply discards messages should not require
any synchronization).
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.
It is pretty high on my list of design goals. I think it is
achievable but will give it up if it proves untenable, but I hate to
be beaten by a problem.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
