commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raman Gupta <>
Subject Re: [logging] logging vs slf4j
Date Mon, 08 Aug 2011 22:17:34 GMT
OK. Note that -- in a similar vein to what you proposed -- I'm also
fine with simply keeping commons-logging as is. The really nice thing
about commons-logging is that it is based on an API (like SLF4j but
unlike jul!).

Therefore, it is really easy for people to do whatever they want --
e.g. for people who use slf4j, we simply ignore commons-logging.jar
and drop in jcl-over-slf4j.jar instead which implements the same jcl
API. The main annoyance is with dependency managers that don't
understand the equivalency and therefore resolve commons-logging.jar,
requiring explicit excludes. This is a manageable problem though.


On 08/08/2011 05:58 PM, Elijah Zupancic wrote:
> Raman,
> 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.
> Thanks,
> -Elijah
> 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:

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

View raw message