On Apr 13, 2007, at 4:59 PM, Paul Smith wrote:
On 14/04/2007, at 1:11 AM, Curt Arnold wrote:
I've been thinking that it might be good to repackage the log4j
1.3 PatternLayout so that it can be used in conjunction with
existing versions of log4j 1.2.x. The process that I'd see is:
1. Fix cosmetic Checkstyle/PMD reported problems for PatternLayout
and associated classes on log4j/trunk
2. Create a sandbox project similar to recent expression-filter
project and copy code over
Should we rather have a log4j-extensions module instead of 1 for
each extra-bit? Is there an advantage to having such fine grained
extension modules?
I think so, but it would be trivial to combine them later if they
make more sense together. The scenario that I was thinking about was
for apps that are already deployed using log4j 1.2.x where the user
would like one specific feature from the log4j 1.3 feature set. So
if you really wanted timezone qualifiers in a layout, you could
optionally mixing just the log4j 1.3 PatternLayout and do any due
necessary testing and code review on just that part.
Code stability and maturity vary. For example, the receivers are
packaged with the log4j 1.3 scheduler code which intermittently fails
its unit tests and has for more than a year. The way it is currently
packed, someone who is just interested in ExpressionFilter or
PatternLayout from log4j 1.3 doesn't need to be concerned about the
scheduler since they aren't adding it to their app.
If you want to bundle up multiple enhancements from the log4j 1.3
code base and start replacing key functionality (like replacing log4j
1.2 PatternLayout with the log4j 1.3 implementation), then I think
you end up with a 1.4 release or a "new" 1.3.
4. Change the package or classname to
org.apache.log4j13.PatternLayout or o.a.l.PatternLayout13 so that
it could be used in conjunction with log4j 1.2.x.
I'd vote for the former, simply because we're likely to use
org.apache.log4j20 or similar for the next version.
The key issue would be the number of classes that need to be
differentiated from their stock log4j 1.2 counterparts. If there is
a lot of duplicate class names, then a distinct package makes more
sense. If not, then it is a style preference. Not hard to tweak
when we have something to tweak.
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.
Actual log4j 2.0 would branch off from step 3 above.
1. Adopt JDK 1.5-isms internally: StringBuilder instead of
StringBuffer, Typed containers, etc
....
Amen!
First though, should we sit back ever so slightly and document up
some overarching goals/principles we wish to follow for log4j2 as
well as a general overall high level design, and plan of attack?
Sort of a 'vision' statement?
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.
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.
On Apr 13, 2007, at 6:47 PM, Paul Smith wrote:
First though, should we sit back ever so slightly and document up
some overarching goals/principles we wish to follow for log4j2 as
well as a general overall high level design, and plan of attack?
Sort of a 'vision' statement?
I'm starting to put together a 'compelling reasons to adopt log4j
2.0' bit of text. I am trying to think about why a fictional user
who has used log4j 1.2 and is thinking about adopting log4j2.0
would choose to make the switch. If we are unable to define what
the compelling advantages of log4j2.0 will be, I think we'll be
starting off on the wrong foot.
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.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
