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 <rocketra...@fastmail.fm> 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: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
