Hi Andreas, I agree with your points about having two different logging APIs and also the dependency problems involving SLF4J. Take a look at the large number of SLF4J exclusions in the WSS4J pom for the Opensaml dependency ;-)
I also accept that the OSGi argument is irrelevant. The argument for moving to SLF4J (for WSS4J) boils down to this then: WSS4J 1.6.0 has dependencies on two logging APIs, because of the Opensaml dependency, where we would only have one if Santuario was ported as well. It's probably not enough of a reason to change the logging API of two projects, so I think I will scrap this task. Colm. On Wed, Apr 6, 2011 at 9:22 PM, Andreas Veithen <[email protected]> wrote: > Colm, > > The argument about OpenSAML may make sense for WSS4J, but it doesn't > apply to Neethi. As pointed out by Dan, the argument about OSGi also > "is irrelevant more or less". This leaves us with a single argument, > namely that having Neethi depend on SLF4J instead of commons-logging > is more convenient for CXF. However, if you look at the other > downstream project, namely Axis2, it's exactly the other way round. > The core Axis2 distribution has no dependency on SLF4J, but uses > commons-logging itself and has several dependencies that use > commons-logging. If we agree that we should not arbitrarily favor one > or the other SOAP stack, then the conclusion right now is that there > is no clear argument in favor of one or the other logging API (for > Neethi). > > My opinion on the commons-logging vs. SLF4J question has always been > that from an architectural perspective, SLF4J has some good points. > However, there are two key issues with SLF4J that annihilate these > advantages: > > 1) When commons-logging was created, it filled a gap that existed in > the Java world, namely the need for a standard abstract logging API. > However, since almost every project and library needs logging, there > is simply not enough room in this space for two competing APIs. The > mistake that SLF4J made was to create yet-another-logging-API instead > of creating a drop-in replacement for commons-logging. By doing so, > they didn't make Java a better place. > > 2) Whenever SLF4J appears in the dependencies of a (Maven) project, > you almost inevitably get into a dependency hell. I explained the > reasons for this in a blog post [1] some time ago. It is also worth > reading the discussion after Woden started to use SLF4J [2] (they > switched to commons-logging afterwards). BTW, OpenSAML is a good > example of how you get into these issues. Here is part of the > dependency tree of that library: > > [INFO] +- org.opensaml:opensaml:jar:2.2.3:compile > [INFO] | +- org.opensaml:openws:jar:1.2.2:compile > [INFO] | | \- org.opensaml:xmltooling:jar:1.2.0:compile > [INFO] | | +- org.slf4j:jcl-over-slf4j:jar:1.5.5:compile > [INFO] | | +- org.slf4j:log4j-over-slf4j:jar:1.5.5:compile > [INFO] | | +- joda-time:joda-time:jar:1.5.2:compile > [INFO] | | +- org.bouncycastle:bcprov-ext-jdk15:jar:1.40:compile > [INFO] | | +- > org.apache.commons.ssl:not-yet-commons-ssl:jar:0.3.9:compile > [INFO] | | \- net.jcip:jcip-annotations:jar:1.0:compile > > Why on earth does this thing have a dependeny on jcl-over-slf4j and > log4j-over-slf4j? I run into this type of problem in almost every > project that somehow depends on SLF4J. Last time was just an hour ago > in Rampart: see r1089599. > > Andreas > > [1] http://veithen.blogspot.com/2009/10/taming-beast-managing-slf4j.html > [2] http://markmail.org/message/zujc7ci5aqwtzjn5 > > On Fri, Apr 1, 2011 at 16:28, Colm O hEigeartaigh <[email protected]> wrote: >> Hi Andreas, >> >> Could you let me know if Dan's mail satisfies your questions about >> moving to SLF4J, or if you still have objections to it? >> >> Just to spell out the logging dependencies, WSS4J 1.6 currently has a >> dependency on slf4j-api via the Opensaml2 dependency. It also has a >> dependency on commons-logging, as this is the logging API that WSS4J >> uses (as well as XML Security). >> >> If we move to use SLF4J, WSS4J 1.6 will have a dependency on slf4j-api >> and on slf4j-jcl, which will be required because of the commons >> logging dependency in XML Security. However, once XML Security 1.5 >> goes out with a switch to SLF4J, we should be in a position to drop >> the slf4j-jcl dependency in WSS4J 1.6.x. >> >> Colm. >> >> On Mon, Mar 28, 2011 at 8:02 PM, Daniel Kulp <[email protected]> wrote: >>> On Monday 28 March 2011 2:40:15 PM Andreas Veithen wrote: >>>> I think there is a flaw in the argument related to OSGi (or at least >>>> something to clarify). You need to make a distinction between the API >>>> against which you code and the actual implementation that you are >>>> using at runtime. In addition to its own API, SLF4J also provides a >>>> re-implementation of the commons-logging API. Therefore it seems to me >>>> that even if SLF4J works better in an OSGi environment, that doesn't >>>> necessary imply that you have to use the SLF4J API. If I understand >>>> [1] correctly, that is the strategy they use for Spring(-DM). >>> >>> Well, with OSGi, it really depends on how you setup your OSGi container. >>> For >>> the most part, *I* would normally recomment using the pax-logging stuff >>> which >>> pretty much exposes all the various logging API's and funnels them into a >>> common place. Thus, the argument is irrelevant more or less. >>> >>> If you setup your own OSGi container and want to strip it down to the VERY >>> basics that are required, then it could be an issue. You would definitely >>> need either commons-logging bundle or the jcl-over-slf4j bundle. That >>> would >>> be one additional bundle compared to just using on slf4j. Likely not a >>> huge >>> deal, but it is an addional dependency. You would still need slf4j-api and >>> an slf4j implementation since the other deps would need it. >>> >>> In this case, I really do agree with Colm. If the two primary dependencies >>> of WSS4J (XMLSec and Opensaml) use slf4j, everyone that uses wss4j are going >>> to need slf4j anyway. However, they may not need commons-logging. Using >>> slf4j in wss4j makes sense to me. >>> >>> For example, with CXF, I think the only two commonly used deps that use >>> commons-logging now are Spring and wss4j. However, a bunch of deps now use >>> slf4j. With 2.4.0, Spring is really quite optional. Thus, commons-logging >>> usage is really just delegated to wss4j. If that could be eliminated, that >>> would be a good thing. Again, helps with stripping down the runtime for >>> the >>> lighter weight, embedded use cases. >>> >>> >>> Dan >>> >>> >>> >>> >>>> >>>> Andreas >>>> >>>> [1] >>>> http://static.springsource.org/osgi/docs/1.0.2/reference/html/spring-osgi- >>>> faq.html#logging >>>> >>>> On Thu, Mar 24, 2011 at 11:34, Colm O hEigeartaigh <[email protected]> >>> wrote: >>>> > I'm thinking about porting WSS4J 1.6 to use SLF4J as well. Currently >>>> > it uses Commons Logging. WSS4J 1.6 has a dependency on Opensaml2 which >>>> > uses SLF4J. I'm hoping to get XML Security 1.5.0 out in a couple of >>>> > months, which will be picked up by WSS4J 1.6.1 or 1.6.2, and which >>>> > will also move from commons logging to SLF4J. If the two most >>>> > important dependencies of WSS4J are using SLF4J, it makes sense for >>>> > WSS4J to use it as well, given that this is a major version change. >>>> > Obviously, the other important reason is out of the box OSGi support >>>> > for SLF4J. >>> >>> >>> -- >>> Daniel Kulp >>> [email protected] >>> http://dankulp.com/blog >>> Talend - http://www.talend.com >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
