I agree - the ability to log objects instead of strings only provides some capabilities which aren't available otherwise - filters are an example (see reflectionfilter & mapfilter in 1.3alpha).
Scott Deboy COMOTIV SYSTEMS 111 SW Columbia Street Ste. 950 Portland, OR 97201 Telephone: 503.224.7496 Cell: 503.997.1367 Fax: 503.222.0185 [EMAIL PROTECTED] www.comotivsystems.com -----Original Message----- From: Jess Holle [mailto:[EMAIL PROTECTED] Sent: Wed 4/4/2007 1:20 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(). -- Jess Holle --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
<<winmail.dat>>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
