- 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).
- 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.
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 am +1 for my above proposal.
-Mark
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
