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.
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
