I would like to add that the slf4j 1.2 branch will also proceed with
releases when there is a change/updated for the slf4j interfaces, not just
releases of log4j 1.2.X. Not sure what the version number would look like,
but it should be similar to the base log4j 1.2.X release it is based on.
Maybe log4j-1.2.11.x1.jar ('x' for eXperimental) or log4j-1.2.11.slf4jb3.jar
which captures the support slf4j version on top of the base logj4 release.
-Mark
> -----Original Message-----
> From: Mark Womack [mailto:[EMAIL PROTECTED]
> Sent: Thursday, May 19, 2005 7:22 AM
> To: Log4J Developers List
> Subject: [VOTE] slf4j support in log4j 1.2.X
>
> 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.
>
> - 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
