logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <ggreg...@seagullsoftware.com>
Subject RE: 1.3 - A Line in the Sand
Date Wed, 04 Apr 2007 21:31:12 GMT
> -----Original Message-----
> From: Jess Holle [mailto:jessh@ptc.com]
> Sent: Wednesday, April 04, 2007 1:21 PM
> To: Log4J Developers List
> Subject: Re: 1.3 - A Line in the Sand
>
> 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().

I agree, typing a logging API to Object make sense. Our applications now count on this behavior
and implement toString() methods as appropriate. IMO, it would be a step backwards for force
a data type, String in this case, when it is not needed, especially considering that toString()
is implemented in Object.

Gary

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


Mime
View raw message