logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Smith <psm...@aconex.com>
Subject Re: log4j 1.3 PatternLayout repackaging and initial log4j 2.0 work
Date Sat, 14 Apr 2007 07:57:49 GMT
> 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?


To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message