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?
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'm very keen to encourage other developers to want to participate
and having this openly visible gives everyone a similar reference
point to aim at. We obviously need not be hasty in granting
committer privs, but I would dearly love to build up the dev
community to ensure it's health.
I'm definitely all about community discussion and participation.
Things do need to be jump-started a bit so we have a basis for
discussion and experimentation. I have had a lot of things that I
could say but didn't think it was beneficial to spew them out when
their wasn't any code shortly forthcoming. Without code we can
have a lot of meaningless arguments without any basis for
experimentation and conclusions.
I'm all in favour in seeing code snippets up front etc, but I'm
hoping we don't simply 'dive in' and start building without having a
clear goal that everyone is on board with. Obviously articulating
ideas will require some isolated code examples etc.
The thing that can't (in my opinion) be accomplished without a
pretty thorough redesign is fine-grain concurrency. Currently
log4j is effectively bottlenecked at one logging event in the
dispatch pipeline at a time which can be a performance bottleneck
on multi-processor systems. There are obvious places that would be
unsafe if that bottleneck was removed (like reused StringBuffers)
and a huge number of potential concurrency issues.
Yes, concurrency is one very weak point of log4j12 and is already on
my list. Relying on JDK 1.5 and it's concurrency package is going to
make life a lot easier (all hail Doug Lea and team).
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?
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
