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?

Paul

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


Mime
View raw message