I won't have time to help on this, so if others feel it's important, go ahead, but since the fork exists, folks who are interested in using slf4j with log4j 1.2.x already have a way to do that.
One other issue to consider is that how we choose to integrate slf4j into 1.2.x (if we do) may be different from how we integrate slf4j into 1.3 (the issue needs to be researched further). I'd prefer we focus on finishing up the minor changes that have been discussed re: 1.2.x (trace, etc.), but leave slf4j integration as a 1.3 issue. Ceki may choose to integrate any changes we make to 1.2.x to his fork, and that's fine with me. Scott -----Original Message----- From: Curt Arnold [mailto:[EMAIL PROTECTED] Sent: Thu 5/19/2005 3:38 PM To: Log4J Developers List Cc: Subject: Re: [VOTE] slf4j support in log4j 1.2.X On May 19, 2005, at 9:22 AM, Mark Womack wrote: > I was hoping that Ceki would decide to drive this, but since he > appears to be unwilling, choosing to instead create a fork of log4j > 1.2.9 within the slf4j group (NLOG4J), I am going to pick this up. > Being the optimist, I believe there is a solution that will work > here. The rest of you can take a break and get your cyanide pills > ready before starting to read the rest of this message. > > - I think that we all agree that supporting slf4j within log4j is a > great idea, and idea we really want to support. We want to see > slf4j succeed, hopefully replacing or augmenting the JCL is some > way that resolves the current JCL classloading/discovery issues > (however that works out). Depends on the interpretation of "supporting slf4j within log4j". I'd have no problem with "supporting slf4j for log4j". Maybe "within" is the best way to achieve "for", but I'm skeptical. > > - One of the ways to give slf4j some immediate support is to > implement the current slf4j interfaces within the log4j 1.2 code > base, and not waiting for the upcoming 1.3 release for the first > slf4j implementation in log4j. > > - However, I also think that many of us have some very valid > concerns about releasing an "official" version of log4j 1.2.X based > on the current slf4j interfaces due to the fact that those > interfaces are still beta and even the slf4j team is expecting to > change the interfaces as they explore and evolve the slf4j > solution. The recent change in the slf4j interfaces from ULogger > to Logger is a simplistic example. I'm sure there will be more to > come. > > - There are also at least two possible goals for an slf4j > implementation within log4j 1.2: > > 1) Provide an implementation of the slf4j interface in the latest > version of log4j 1.2. > 2) Provide an implementation of the slf4j interface that is > compatible with all 1.2.X versions of log4j. > > These goals suggest different approaches and implementations > (direct vs facade). I would suggest that it is goal #1 that is > more important. As long as the direct implementation is backward > compatible with the existing 1.2 api and the implementation does > not cause lots of unexpected changes and stability issues, spending > time on the facade version is only important if you really want to > support goal #2. I personally do not think it is as important. I think the facade approach has other benefits in addition to being able to support deployed versions of log4j, particularly isolating log4j from the revision cycle of slf4j. > > With these points in mind, I would like to submit the following > proposal: > > 1) That we create a branch of the 1.2 source code that implements > the current slf4j interfaces. > 2) That we release versions from this branch to correspond to the > current log4j 1.2.x release going forward. This slf4j 1.2 branch > will be kept up to date with the latest changes in the main > 1_2branch that are are not related to slf4j changes. > 3) The releases from the slf4j 1.2 branch will be released and > named with some "experimental" moniker (still not sure what the > right term/phrase should be here) until such time the log4j > committers determine for themselves that the slf4j interfaces are > "solid" or "frozen". At that point there can be a proposal to > merge the slf4j 1.2 branch back into the main 1_2branch and release > an "official" version of log4j 1.2 with full slf4j support. > Hopefully they will have been hashed out by them, but if there are > still concerns about direct vs facade implementations, they can be > part of the discussion/decision. If people feel that a facade > implementation is really important, there is nothing stopping us > from working on it in parallel to the direct version for comparison. > 4) None of this makes any difference to the 1.3 release or branch. > It has ongoing efforts to support the latest slf4j interfaces > directly. > > If this proposal is accepted, then the need and confusion around > the slf4j's NLOG4J goes away, as far as I can tell. Slf4j can > obviously do what it wants, but having a supported, "experimental" > version of log4j w/slf4j support is certainly no worse than having > NLOG4J. And, I believe, is actually better since it provides some > clarity to log4j users as to what is going on with respect to an > implementation in the log4j api/base. I'd really like to be able to take a few days to work out a facade implementation before we take actions that appear to be making a statement that only a direct implementation can be efficient. There are two direct implementations in the wild, log4j 1.3 CVS HEAD and NLOG4J, adding a third doesn't add any new information. If we allow a little time to put together a facade implementation, we'd have some basis for comparing a facade based approach and a direct implementation approach. I won't veto the proposal, but I do think it is premature. If the repo is branched for a direct SLF4J implemention, then I'd like to reserve the right to ask for a separate branch for a facade implementation. -0 --------------------------------------------------------------------- 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]
