Can we please not get sidetracked from the core issues? They are: * should we do logging via a MyFaces logging api, to avoid direct dependencies between lots of MyFaces classes and *any* external logging library? * are external dependencies allowed in the API jarfile? Once we sort those out, then we can debate whether to choose commons-logging or SLF4J.
My apologies Simon, I didn't mean to sidetrack this issue. My two cents is that avoiding dependencies should not be a priority for the sake of itself. If there is an external library that is compelling enough in its usefulness then I don't see the problem with taking advantage of it. I mentioned SLF4J, first of all because I was surprised that no-one had mentioned it previously, and secondly because it is specifically designed to eliminate the dependency on any single external logging library (it is not a logging implementation itself), which seems to be the foremost goal of this thread.
So, +1 from me for allowing an external dependency.
Regards,
Shane
Regards, Simon Travis Reeder wrote: > That looks like a very interesting option, I really like the formatted > way of showing the messages and the simple runtime jar swap to switch > implementations. > > Travis > > On 12/15/05, *Shane Bryzak* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > How about using SLF4J? (http://www.slf4j.org/) > <http://www.slf4j.org/%29> For anyone that doesn't know what this > is, here's an excerpt from the site: > > "The Simple Logging Facade for Java or (SLF4J) is intended to serve > as a simple facade for various logging APIs allowing to the end-user > to plug in the desired implementation at /deployment/ time. SLF4J > also allows for a gradual migration path > <http://www.slf4j.org/manual.html#gradual> away from Jakarta Commons > Logging (JCL)." > > It's written by Ceki Gulcu (who also wrote Log4J) and is compatible > with the Apache license. I'm using it successfully in production > code right now, and the great thing about it is that it defers the > choice of logging API to the user at deployment time. > > Regards, > > Shane > > > > On Fri, 2005-12-16 at 09:35 +1300, Simon Kitching wrote: >> Hi Mario, >> >> Mario Ivankovits wrote: >> > Why wouldnt you create this wrapper library under the umbrella of >> > commns-logging? >> > Different commons-logging libraries using static linking instead of the >> > dynamic behaviour. >> > Say: commons-logging-log4j, commons-logging-jdklogger >> >> This sort of thing is under *consideration* for commons-logging 2.0. >> However there are a number of limitations to this approach. You can find >> discussions on this in the commons email archives, and see experimental >> implementations of various sorts in the commons-logging SVN tree. It's >> not just as simple as code-it-and-release. >> >> > I think it isnt that a good idea if every project comes with its own >> > wrapper library. In the worst case this will double the number of >> > libraries used - even more logging hassle. >> >> What I have proposed for MyFaces is *not* the same thing at all. Have a >> look at the code I've attached here: >> http://issues.apache.org/jira/browse/MYFACES-949 >> >> This solution is very lightweight and has fairly good performance. >> However as the javadoc on those classes describe, this does *not* allow >> logging implementations to be swapped at runtime like commons-logging >> does. The patch I've proposed requires a *recompilation* of the MyFaces >> code in order to swap logging libraries. That's the price paid for >> having a lightweight solution (so few lines of code). >> >> And that's not an approach that can be build into commons-logging! >> >> Despite recompilation being required, it *does* centralise the >> dependency on the underlying library into *one* class, rather than >> having classes all over the MyFaces library depending directly on >> commons-logging. >> >> It also means that someone can come along and modify that single class >> to use something other than commons-logging, so that MyFaces doesn't >> depend on *any* jar with org.apache.commons.logging classes in it. >> >> Regards, >> >> Simon > >
