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.
In my opinion, obsessing over total/absolute/100% backward compatibility is a guaranteed recipe for project failure.
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.
Jake >cheers,
-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
