logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Womack <wom...@adobe.com>
Subject RE: [VOTE] slf4j support in log4j 1.2.X
Date Fri, 20 May 2005 18:26:32 GMT
Comments below.

> -----Original Message-----
> From: Curt Arnold [mailto:carnold@apache.org]
> Sent: Thursday, May 19, 2005 3:38 PM
> To: Log4J Developers List
> Subject: Re: [VOTE] slf4j support in log4j 1.2.X
> 
> 
> > - 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.

At this point I meant the more generic "supporting the slf4j project from
the log4j project".  I was not trying to be so concrete as to whether the
implementation is in the jar or in a separate jar.

> >
> > - 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.

Yeah, it depends on how quickly the slf4j api's change and how quickly we
want to release new versions of log4j to support it.  Even beyond the
current beta evolution of the slf4j api's.

> 
> 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.

Go for it.  And one of the implied goals of the proposal is to replace
nlog4j with a release from the log4j project (though slf4j will need to make
that determination).  I think that will make it clearer to the user base
what is going on.

> 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

Absolutely.

-Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message