You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ws.apache.org by Colm O hEigeartaigh <co...@apache.org> on 2011/04/01 16:28:20 UTC
Re: svn commit: r1083862 - in /webservices/commons/trunk/modules/neethi:
pom.xml src/main/java/org/apache/neethi/PolicyBuilder.java
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 <dk...@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 <co...@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
Re: svn commit: r1083862 - in /webservices/commons/trunk/modules/neethi:
pom.xml src/main/java/org/apache/neethi/PolicyBuilder.java
Posted by Colm O hEigeartaigh <co...@apache.org>.
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
<an...@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 <co...@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 <dk...@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 <co...@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
Re: svn commit: r1083862 - in /webservices/commons/trunk/modules/neethi:
pom.xml src/main/java/org/apache/neethi/PolicyBuilder.java
Posted by Andreas Veithen <an...@gmail.com>.
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 <co...@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 <dk...@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 <co...@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