commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Elijah Zupancic <>
Subject Re: [logging] logging vs slf4j
Date Mon, 08 Aug 2011 21:58:42 GMT

You may have proposed this earlier in the thread and I didn't catch
it. I actually like your suggestion the best, but it seems like it is
a difficult sell for a lot of people to compile against the slf4j API
for a variety of reasons that are not strictly code related.

My suggestion was intended to bridge the gap between the concerns
toward compiling directly against slf4j.

Another option is to try to work with Ceki to address some of the
concerns of the commons community with regards to using slf4j.

>From what I can tell from the thread, here are the following points
against SLF4J:

* Log4j developer V2 would like to see the Apache community support
the project rather than putting resources into slf4j.
* Slf4j apparently has some deficiencies in its API such as: "SLF4J
has to convert the EventData object to XML since SLF4J/Logback don't
provide a good way of handling this."
* Log4j V2 also implements support for the Slf4j API.
* There is a hassle with too many jars for dependencies with slf4j.
* Every time Ceki goes on vacation everything stops.
* Some have a preference for Apache driven projects.
* Figuring out the dependencies that are needed can be difficult.

If we can come to some consensus regarding this issues, then I think
there will be more traction toward Slf4j.


On Mon, Aug 8, 2011 at 2:13 PM, Raman Gupta <> wrote:
> On 08/08/2011 04:56 PM, Elijah Zupancic wrote:
>> This could be done by choosing (dynamically or by configuration) the
>> logger implementation log4j / commons / slf4j / jul and then loading
>> the LoggerFactory into a wrapper class that is then called used by the
>> Commons project.
>> We would then make the logger implementations a compile-time
>> dependency only and relay upon the consumer to provide them.
>> I do realize that this is essentially doing a Facade on top of a
>> Facade, but it solves the problem for consumers of the library by
>> providing many options.
>> So, am I crazy?
> If I understand you correctly, you would have this dependency chain:
> random-commons-project ->
>  commons-logging-wrapper ->
>    API like slf4j or logging implementation (at runtime)
> Plus commons-logging-wrapper requires compile-time knowledge of all
> possible target frameworks, since it is not coding to an API.
> Can you explain the advantage over simply coding
> random-commons-project against slf4j-api.jar? Then, you have this
> dependency chain:
> random-commons-project ->
>  slf4j-api ->
>    logging implementation (at runtime)
> And anyone can create their own slf4j compatible logging
> implementation simply by implementing the slf4j api and dropping their
> jar into their environment.
> Cheers,
> Raman
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message