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 Mark Womack <mw...@apache.org> on 2005/07/28 05:08:52 UTC

1.2.12 Open Bug Review

For the bugs that have been marked as "1.2.12 candidate" that are still 
open, here is the current review:

14551, 17227, 18122, 30804, 30819 are Javadoc related.

24159 - declined, will not be fixed for 1.2.12.

26345 - may be too dangerous, need to review some more.  Opinions?

31727 - declined, don't know what I was thinking.

33624 - I will be looking at this.

34026 - I think we should still fix this.  Opinions?

If I am not mistaken, we still need to test serialization with the new TRACE 
level added?  If so, then I can write a bug on it.

-Mark 



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


RE: 1.2.12 Open Bug Review

Posted by Mark Womack <wo...@adobe.com>.
> > 33624 - I will be looking at this.
> 
> Go Mark Go.
> 
> >
> > 34026 - I think we should still fix this.  Opinions?
> 
> Go Mark Go.

Going to look at them tonight.

> >
> > If I am not mistaken, we still need to test serialization with the
> > new TRACE level added?  If so, then I can write a bug on it.
> 
> I ported the serialization tests from log4j 1.3 back to the log4j 1.2
> branch (Bug 26433) a few weeks ago before adding TRACE.  Adding trace
> (and the other changes) did not break the tests which makes me feel
> relatively comfortable that none of the changes have broken
> serialization.  I did not add any of the unit test bugs to docs/
> HISTORY.txt since the tests are not in the distribution.
> 
>  From a code review, I believe that an older Chainsaw will not
> recognized the TRACE_LEVEL in the serialized LoggingEvent but will
> map it to Level.DEBUG which seems like reasonable behavior.  However,
> it would be good if somebody could do a sanity check  and fire up
> Chainsaw and see if it works okay.

That is good news.  Paul, Scott, someone using Chainsay, can you try
1.2.12rc1 with the old/new Chainsaw and see how it performs with the new
TRACE?

If anyone else has a log4j setup that uses serialization, if you can
substitute 1.2.12rc1 and report back your findings, that will be helpful
too.

Thanks,
-Mark


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


Re: 1.2.12 Open Bug Review

Posted by Curt Arnold <ca...@apache.org>.
On Jul 27, 2005, at 10:08 PM, Mark Womack wrote:

> For the bugs that have been marked as "1.2.12 candidate" that are  
> still open, here is the current review:
>
> 14551, 17227, 18122, 30804, 30819 are Javadoc related.
>
> 24159 - declined, will not be fixed for 1.2.12.
>
> 26345 - may be too dangerous, need to review some more.  Opinions?

Probably not a difficult fix, but easy to make big mistake if you  
don't know what you are doing and I don't.

>
> 31727 - declined, don't know what I was thinking.
>
> 33624 - I will be looking at this.

Go Mark Go.

>
> 34026 - I think we should still fix this.  Opinions?

Go Mark Go.

>
> If I am not mistaken, we still need to test serialization with the  
> new TRACE level added?  If so, then I can write a bug on it.

I ported the serialization tests from log4j 1.3 back to the log4j 1.2  
branch (Bug 26433) a few weeks ago before adding TRACE.  Adding trace  
(and the other changes) did not break the tests which makes me feel  
relatively comfortable that none of the changes have broken  
serialization.  I did not add any of the unit test bugs to docs/ 
HISTORY.txt since the tests are not in the distribution.

 From a code review, I believe that an older Chainsaw will not  
recognized the TRACE_LEVEL in the serialized LoggingEvent but will  
map it to Level.DEBUG which seems like reasonable behavior.  However,  
it would be good if somebody could do a sanity check  and fire up  
Chainsaw and see if it works okay.






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


Re: 1.2.12 Open Bug Review

Posted by Mark Womack <mw...@apache.org>.
Thanks to everyone, all of the bugs have now been addressed.  I think we 
should do some more testing around the TRACE change and I want to look a 
performance with the String.intern() change in CategoryKey.  I'll plan to do 
rc2 at the beginning of next week.  Hopefully the user list will have had 
some time to digest the rc1 version by then as well.

-Mark

----- Original Message ----- 
From: "Mark Womack" <mw...@apache.org>
To: "Log4J Developers List" <lo...@logging.apache.org>
Sent: Wednesday, July 27, 2005 8:08 PM
Subject: 1.2.12 Open Bug Review


> For the bugs that have been marked as "1.2.12 candidate" that are still 
> open, here is the current review:
>
> 14551, 17227, 18122, 30804, 30819 are Javadoc related.
>
> 24159 - declined, will not be fixed for 1.2.12.
>
> 26345 - may be too dangerous, need to review some more.  Opinions?
>
> 31727 - declined, don't know what I was thinking.
>
> 33624 - I will be looking at this.
>
> 34026 - I think we should still fix this.  Opinions?
>
> If I am not mistaken, we still need to test serialization with the new 
> TRACE level added?  If so, then I can write a bug on it.
>
> -Mark
>
>
> ---------------------------------------------------------------------
> 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: latest slf4j (was Re: 1.2.12 Open Bug Review)

Posted by Curt Arnold <ca...@apache.org>.
On Aug 2, 2005, at 12:08 AM, Mark Womack wrote:

> Well, the most interesting slf4j development that I saw recently  
> was the new "marker" concept.  Kind of nice way to allow the  
> developer to define "aspects" or "concerns" within their code.   
> Sure does multiply the number of methods though.  It would be nice  
> if there were a way to let the client or configurator control that  
> instead of the original developer, but I can't think of a good way  
> to achieve that.
>
> I saw that Ceki had updated nlog4j to implement the new marker  
> related methods, but just glancing at the changes, they seemed to  
> just be pass thrus to the non-marker versions.  Maybe I missed  
> something there; I did not have time to look closely.
>
> I don't think the slf4j related changes can make it into 1.2.12,  
> and as suspected, the slf4j api is changing and morphing quite a  
> bit.  It is a good thing, as the juices are certainly flowing.  I  
> think we should revisit the slf4j log4j 1.2 implementation again  
> once the api is more "stable".  We can certainly track the api in  
> the main branch.
>
> -Mark


I tried to follow the discussion on slf4j-dev.  The marker effort  
seems way too experimental and novel to be consistent with the  
"Simple Facade" part of SLF4J's full name in my opinion.  I don't  
think it has been enshrined into a beta yet.   The log4j CVS HEAD  
implementation hasn't been updated from 1.0-beta3 to 1.0beta4 and I  
should take a look at that.

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


latest slf4j (was Re: 1.2.12 Open Bug Review)

Posted by Mark Womack <mw...@apache.org>.
Well, the most interesting slf4j development that I saw recently was the new 
"marker" concept.  Kind of nice way to allow the developer to define 
"aspects" or "concerns" within their code.  Sure does multiply the number of 
methods though.  It would be nice if there were a way to let the client or 
configurator control that instead of the original developer, but I can't 
think of a good way to achieve that.

I saw that Ceki had updated nlog4j to implement the new marker related 
methods, but just glancing at the changes, they seemed to just be pass thrus 
to the non-marker versions.  Maybe I missed something there; I did not have 
time to look closely.

I don't think the slf4j related changes can make it into 1.2.12, and as 
suspected, the slf4j api is changing and morphing quite a bit.  It is a good 
thing, as the juices are certainly flowing.  I think we should revisit the 
slf4j log4j 1.2 implementation again once the api is more "stable".  We can 
certainly track the api in the main branch.

-Mark

----- Original Message ----- 
From: "Jacob Kjome" <ho...@visi.com>
To: "Log4J Developers List" <lo...@logging.apache.org>
Sent: Thursday, July 28, 2005 7:57 PM
Subject: RE: 1.2.12 Open Bug Review


> At 03:34 PM 7/28/2005 -0400, you wrote:
> >
> >My goal is still to be done with 1.2 ASAP and push out 1.3.0 (not alpha).
>
> We need to get up-to-date with SLF4J.
>
> Ceki, you know SLF4J and all of its recent changes best.  Would it be 
> possible for you to update the HEAD with the newest SLF4J?  When do you 
> expect SLF4J will be finalized and released as 1.0?  Does 1.0 represent a 
> lock down point for the API, or do you expect more API change after that? 
> Does implementing the SLF4J API, as it stands now, have any impact on 
> supporting binary compatibility of Log4j-1.3 with the 1.2 branch?
>
>
> Jake
>
>
>
>
> ---------------------------------------------------------------------
> 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: 1.2.12 Open Bug Review

Posted by Jacob Kjome <ho...@visi.com>.
At 03:34 PM 7/28/2005 -0400, you wrote:
 >
 >My goal is still to be done with 1.2 ASAP and push out 1.3.0 (not alpha).

We need to get up-to-date with SLF4J.

Ceki, you know SLF4J and all of its recent changes best.  Would it be 
possible for you to update the HEAD with the newest SLF4J?  When do you 
expect SLF4J will be finalized and released as 1.0?  Does 1.0 represent a 
lock down point for the API, or do you expect more API change after 
that?  Does implementing the SLF4J API, as it stands now, have any impact 
on supporting binary compatibility of Log4j-1.3 with the 1.2 branch?


Jake




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


RE: 1.2.12 Open Bug Review

Posted by Yoav Shapira <yo...@MIT.EDU>.
Hi,

> 14551, 17227, 18122, 30804, 30819 are Javadoc related.

I've fixed these on the 1.2 and HEAD branches.

> 26345 - may be too dangerous, need to review some more.  Opinions?

Save for 1.3.

> 34026 - I think we should still fix this.  Opinions?

Minor use-case, save for 1.3.

My goal is still to be done with 1.2 ASAP and push out 1.3.0 (not alpha).

Yoav