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
