[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xmlrpc-user
Subject:    Re: svn commit: r1083862 - in /webservices/commons/trunk/modules/neethi:
From:       Colm O hEigeartaigh <coheigea () apache ! org>
Date:       2011-04-28 15:48:51
Message-ID: BANLkTikk9KEJ-c0CHDB8fX3kU53Kkz1xOQ () mail ! gmail ! com
[Download RAW message or body]

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
<andreas.veithen@gmail.com> 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 <coheigea@apache.org> 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 <dkulp@apache.org> 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 <coheigea@apache.org>
>>> 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
>>> dkulp@apache.org
>>> http://dankulp.com/blog
>>> Talend - http://www.talend.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: dev-help@ws.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: dev-help@ws.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]