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]
