logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jess Holle <je...@ptc.com>
Subject Re: 1.3 - A Line in the Sand
Date Wed, 04 Apr 2007 20:20:50 GMT
Ceki Gülcü wrote:
> At 07:10 AM 4/3/2007, Jacob Kjome wrote:
>
>> I think it's been said before that 1.3 may be more of a dead end than 
>> anything else.  Some interesting things went into it, but the fact 
>> that it became so incompatible with Log4j-1.2.xx is a real problem.  
>> Is it worth a release or do we just leave it as-is, forever alpha, 
>> and move on to 2.0?
> For most intents and purposes 1.3 is compatible with 1.2. I'd say that 
> 99.% percent of users will be able to use it out of the box. A very 
> small minority will need to make a few changes, either in their config 
> files or tweaking their extensions of log4j.
I'd agree that this is *now* the case.  Not that long ago (i.e. last 
calendar year when I first tried 1.3.x), 1.3.x had broken binary 
compatibility with fairly basic usage of 1.2.x APIs.
> In my opinion, obsessing over total/absolute/100% backward 
> compatibility is a guaranteed recipe for project failure.
I'd agree actually.
>> As long as we're considering things that have been ignored for a 
>> while, what is our official take on Logback?  It's basically a 
>> realization of what Log4j-1.3 was supposed to be, no?  Do we really 
>> have plans to best it as Log4j-2.0?  I'm not saying we don't.  I'm 
>> just asking the question.  And what are we going to do about SLF4J?  
>> It's gained significant acceptance and we've punted on how we are 
>> going to approach it; implement it directly, write a wrapper for it 
>> (actually, this has already been done by the SLF4J team), or ignore 
>> it altogether.  So far, we've chosen the latter as the path of least 
>> resistance.
> Contrary to UGLI, SLF4J API forces messages to be of type String (not 
> Object). As NLOG4J has shown, you can get away with it, but it will 
> force users to recompile. On the other hand, natively implementing 
> SLF4J will work much better in presence of repo-selectors
I noticed that SLF4J (and apparently logback at a glance) force messages 
to be of type String.

This is a *huge* step backwards as I see it.  There are some *really* 
compelling things that can be done by having Object messages -- apart 
from the simple (but useful) lazy invocation of toString().

--
Jess Holle

---------------------------------------------------------------------
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