ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm O hEigeartaigh <cohei...@apache.org>
Subject Re: svn commit: r1083862 - in /webservices/commons/trunk/modules/neethi: pom.xml src/main/java/org/apache/neethi/PolicyBuilder.java
Date Fri, 01 Apr 2011 14:28:20 GMT
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


Mime
View raw message