On Apr 14, 2007, at 2:57 AM, Paul Smith wrote:
I was thinking that org.apache.logging would be the base package
for new stuff. org.apache.logging.log4j would be the home for a
(at least mostly) source code compatible API. Other stuff that
works with both the log4j API and the java.util.logging API might
be in org.apache.logging.appender or org.apache.logging.layout or
something similar. I think other package name issues will get
clearer once we get into separating API from implementation
bundles with OSGi which is a long way away.
I'm going to need to do some reading on OSGI, but one thing I think
we should consider is that logging packages generally don't have
any dependencies, so I'm hoping that at least the 'core' log4j2 is
quite standalone. I think requiring log4j2 at it's core to rely on
an external package _might_ reduce uptake? I'll need to understand
OSGI more. I hear Apache Felix is moving out of the incubator
shortly. Has anyone played with that yet?
Playing with Felix and OSGi has been on my long to-do list for a long
time. I did sit in on presentations of OSGi and Felix at the last
two US ApacheCON's, but haven't gotten my feet dirty. I have noticed
a bit of traffic on the logback mailing lists regarding OSGi.
I know that it has package name conventions to distinguish between
published API and implementation details that could be useful to
follow even if there is no other dependency.
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.
Design principles could pretty much be summed up to read and
follow "Effective Java" (Second Edition coming soon) and "Java
Concurrency in Practice". Cover everything with unit tests,
ideally test first design. Code defensively, don't code that
depends other code not doing something unexpected. Design for
concurrency.
What about Inversion of Control principles? I'm not suggesting the
use of Spring etc obviously, but the general IoC principles make
things really easy to mock out and test.
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.
I'd also like to see the "back-end" components like appenders and
layouts work effectively with multiple front-end APIs,
particularly java.util.logging.
I'm not sure I quite get that one. Any chance you could expand on
that?
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
