You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Ralph Goers <Ra...@dslextreme.com> on 2008/06/19 08:35:26 UTC

Log4J 2.0

The website says there is an experimental branch for log4j 2.0 
development, but I can't seem to find it. I looked at the wiki and I 
don't see anything there discussing what log4j 2.0 should be. A month or 
so ago I searched the archives and did find the discussions around 
stopping 1.3 and some discussion about 2.0 but that just seemed to die.

I am very interested in a "new and improved" log4j and would love to be 
involved in making that happen. But before writing any code it might be 
nice to document just what 2.0 should be. For example, I believe there 
is general agreement that 2.0 should leverage Java 1.5. But what about 
implementing AOP constructs such as automatic method entry and exit 
logging, borrowing from some of the features added to SLF4J such as 
Markers and TurboFilters, etc.

Thoughts?

Ralph

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


Re: Log4J 2.0

Posted by Ralph Goers <Ra...@dslextreme.com>.
Curt Arnold wrote:
>
> On Jun 19, 2008, at 8:41 PM, Ralph Goers wrote:
>
>> I'm also happy to see you'd like to change the configuration. I'd 
>> actually like to make that pluggable, but I guess I'd also be happy 
>> using something like commons-logging, as long as their aren't any 
>> circularity conflicts.
>
> Internal logging should be less significant in log4j 2.0 since lower 
> level stuff should be reporting problems with exceptions instead of 
> quietly swallowing them. Where internal logging becomes necessary, I'd 
> lean toward OSGi's logging facility, however I think it is a long way 
> off before figuring that out.
Sorry. Fingers didn't type what the mind was thinking. I meant 
commons-configuration, not commons-logging. commons-logging makes no 
sense in the context of pluggable configuration.

Ralph


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


Re: Log4J 2.0

Posted by Curt Arnold <ca...@apache.org>.
On Jun 19, 2008, at 8:41 PM, Ralph Goers wrote:

> Thanks, I see the various Jira issues you have started. That is  
> great. Unfortunately my work laptop died today and I'll probably end  
> up spending most of the evening reinstalling stuff on it. I will  
> make sure I add what I would like to see by the end of the weekend.
>

Thanks.  Don't be afraid to put up half-baked or stretch ideas up  
there.  None of the things I put up should be considered sacrosanct.   
Feel free to comment on any of my bugs.  Was just trying to get my  
thoughts out there.

> I have one concern about the issue where 2.0 should be "generally  
> api compatible". IIUC the Category class has been deprecated for a  
> long time. I think that should be fair game to cleanup.

Category and Priority should not be in our new prime API and  
definitely not in the core.  Whether our generally log4j 1.2 API is  
the prime API or a compatibility API is not clear at the moment and  
that may determine if Category and Priority stay or go in that API.   
Worth a note in the bug report however.  Haven't thought too much  
about new APIs.

> I'm also happy to see you'd like to change the configuration. I'd  
> actually like to make that pluggable, but I guess I'd also be happy  
> using something like commons-logging, as long as their aren't any  
> circularity conflicts.

Internal logging should be less significant in log4j 2.0 since lower  
level stuff should be reporting problems with exceptions instead of  
quietly swallowing them. Where internal logging becomes necessary, I'd  
lean toward OSGi's logging facility, however I think it is a long way  
off before figuring that out.
>
>
> I would love to have commit access, even if it is only to the branch  
> where the new work will occur, but I will leave that up to the  
> community to decide.
>

I'm thinking that general log4j commit rights would be the right long  
term solution.  log4j 2.0 development would likely involve writing  
unit tests for log4j 1.2 to capture behavior.  Also spreading  
maintenance tasks for log4j 1.2 around would also allow log4j 2.0 to  
proceed faster.

> Ralph
>
> Curt Arnold wrote:
>>



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


Re: Log4J 2.0

Posted by Ralph Goers <Ra...@dslextreme.com>.
Thanks, I see the various Jira issues you have started. That is great. 
Unfortunately my work laptop died today and I'll probably end up 
spending most of the evening reinstalling stuff on it. I will make sure 
I add what I would like to see by the end of the weekend.

I have one concern about the issue where 2.0 should be "generally api 
compatible". IIUC the Category class has been deprecated for a long 
time. I think that should be fair game to cleanup. I'm also happy to see 
you'd like to change the configuration. I'd actually like to make that 
pluggable, but I guess I'd also be happy using something like 
commons-logging, as long as their aren't any circularity conflicts.

I would love to have commit access, even if it is only to the branch 
where the new work will occur, but I will leave that up to the community 
to decide.

Ralph

Curt Arnold wrote:
>
> On Jun 19, 2008, at 1:35 AM, Ralph Goers wrote:
>
>> The website says there is an experimental branch for log4j 2.0 
>> development, but I can't seem to find it.
>
> I did some experiments a year ago in 
> http://svn.apache.org/repos/asf/logging/sandbox/experimental/pattern-layout that 
> capture several of my ideas at the time on reworking the back end 
> classes.  I didn't want to brand that experiment as the start of log4j 
> 2.0 until there was some consensus.  See 
> http://marc.info/?l=log4j-dev&m=117778958715164&w=2
>
>> I looked at the wiki and I don't see anything there discussing what 
>> log4j 2.0 should be.
>> A month or so ago I searched the archives and did find the 
>> discussions around stopping 1.3 and some discussion about 2.0 but 
>> that just seemed to die.
>>
>> I am very interested in a "new and improved" log4j and would love to 
>> be involved in making that happen.
>
> You would be very much welcomed.  Since you are an Apache member, we 
> should be able to expedite a vote on commit privileges.
>
>
>> But before writing any code it might be nice to document just what 
>> 2.0 should be. For example, I believe there is general agreement that 
>> 2.0 should leverage Java 1.5. But what about implementing AOP 
>> constructs such as automatic method entry and exit logging, borrowing 
>> from some of the features added to SLF4J such as Markers and 
>> TurboFilters, etc.
>>
>
> There is a JIRA set up to collect potential log4j 2.0 features 
> (http://issues.apache.org/jira/browse/LOG4J2).  It is pretty empty at 
> the moment.  Feel free to add any features (in the most generic sense) 
> that you think should be considered for log4j 2.0.
>
> I'd prefer if you would explain the use case and motivation for a 
> feature in a bug report unless you really really need an identical 
> solution, in that case, do both the general use case as one bug as a 
> different bug for the specific solution.  So instead of saying "log4j 
> 2.0 needs markers", so "cross-cuts on logging hierarchy" as one bug 
> and "SLF4J style markers" as another and explain the motivation.
>
>
>> Thoughts?
>>
>> Ralph
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>

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


Re: Log4J 2.0

Posted by Curt Arnold <ca...@apache.org>.
On Jun 19, 2008, at 1:35 AM, Ralph Goers wrote:

> The website says there is an experimental branch for log4j 2.0  
> development, but I can't seem to find it.

I did some experiments a year ago in http://svn.apache.org/repos/asf/logging/sandbox/experimental/pattern-layout 
  that capture several of my ideas at the time on reworking the back  
end classes.  I didn't want to brand that experiment as the start of  
log4j 2.0 until there was some consensus.  See http://marc.info/?l=log4j-dev&m=117778958715164&w=2

> I looked at the wiki and I don't see anything there discussing what  
> log4j 2.0 should be.
> A month or so ago I searched the archives and did find the  
> discussions around stopping 1.3 and some discussion about 2.0 but  
> that just seemed to die.
>
> I am very interested in a "new and improved" log4j and would love to  
> be involved in making that happen.

You would be very much welcomed.  Since you are an Apache member, we  
should be able to expedite a vote on commit privileges.


> But before writing any code it might be nice to document just what  
> 2.0 should be. For example, I believe there is general agreement  
> that 2.0 should leverage Java 1.5. But what about implementing AOP  
> constructs such as automatic method entry and exit logging,  
> borrowing from some of the features added to SLF4J such as Markers  
> and TurboFilters, etc.
>

There is a JIRA set up to collect potential log4j 2.0 features (http://issues.apache.org/jira/browse/LOG4J2 
).  It is pretty empty at the moment.  Feel free to add any features  
(in the most generic sense) that you think should be considered for  
log4j 2.0.

I'd prefer if you would explain the use case and motivation for a  
feature in a bug report unless you really really need an identical  
solution, in that case, do both the general use case as one bug as a  
different bug for the specific solution.  So instead of saying "log4j  
2.0 needs markers", so "cross-cuts on logging hierarchy" as one bug  
and "SLF4J style markers" as another and explain the motivation.


> Thoughts?
>
> Ralph




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


Re: Log4J 2.0

Posted by Jess Holle <je...@ptc.com>.
Ralph Goers wrote:
> The website says there is an experimental branch for log4j 2.0 
> development, but I can't seem to find it. I looked at the wiki and I 
> don't see anything there discussing what log4j 2.0 should be. A month 
> or so ago I searched the archives and did find the discussions around 
> stopping 1.3 and some discussion about 2.0 but that just seemed to die.
>
> I am very interested in a "new and improved" log4j and would love to 
> be involved in making that happen. But before writing any code it 
> might be nice to document just what 2.0 should be. For example, I 
> believe there is general agreement that 2.0 should leverage Java 1.5. 
> But what about implementing AOP constructs such as automatic method 
> entry and exit logging, borrowing from some of the features added to 
> SLF4J such as Markers and TurboFilters, etc.
My big item for 2.0 is better handling of multi-threading (better thread 
safety, less locking, less granular locking, more efficient locking 
constructs courtesy of Java 5, etc).  As per threads on this list I've 
made my own stabs at point improvements in this area on top of 1.2 for 
my usage, but can quite understand that this is not the way to go for 
the 1.2.x stream.

For AOP I've found it quite easy to just use AspectJ to trigger calling 
log4j when/where I want.  I'm not sure what advantage it would give to 
lock folk into a particular AOP toolset.  It might be good to have 
extras bundles for use of log4j with one or more popular AOP tools, though.

--
Jess Holle


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