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