I think there is some confusion about the goals of SLF4J. First, SLF4J is not about killing JCL. JCL answers a need by some users who wish to be able to switch implementations if the need arises. JCL's current implementation was driven by another less well known goal related to isolation of logging environments in web-apps. JCL's dynamic discovery mechanism provides a solution to both problems simultaneously.
JCL is non-intrusive in the sense that it wraps logging implementations which do not need to know that they are being wrapped by JCL. In contrast, SLF4J is designed with the needs of a logging framework fist and users' needs second. This inverted set of priorities may paradoxically result in better user satisfaction. The point being that SLF4J is intended to be implemented *directly* by the logging frameworks which decide to use it even if SLF4J can also wrap a logging framework, but with lesser results.
More below.
At 16:22 5/19/2005, Mark Womack wrote:
> These goals suggest different approaches and implementations (direct > vs facade).
At 16:22 5/19/2005, 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).
- 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.
I would not expect SLF4J to evolve much beyond its current state but unfortunately it's not something I could guarantee. As for the ULogger -> Logger change, please note that it would have been handled quite differently had log4j 1.2.10 were officially endorsed.
- 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).
The term "facade" maybe a little ambiguous here. Did you mean "direct" vs "wrapping"?
Wrapping is non-intrusive while a direct implementation creates a dependency. A direct implementation allows for a simpler, leaner and more robust code but with all the inconveniences associated with having an extra-dependency.
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.
Thank you for this compromising proposal. As indicated previously, I'd be more than happy to scrap NLOG4J as soon as the 1.2 branch offers a reasonable alternative implementation.
Judging from earlier responses, I do not sense overwhelming enthusiasm for your proposal. In the present situation, it may be perhaps wiser to let a strong consensus emerge rather than agree on a compromise solution no one is really happy with.
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
-- Ceki G�lc�
The complete log4j manual: http://www.qos.ch/log4j/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
