> -----Original Message----- > From: Jess Holle [mailto:[EMAIL PROTECTED] > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
