OK, thanks. On 04/13/2012 02:10 PM, Colm O hEigeartaigh wrote: > Hi Alessio, > > OpenSAML is also required for adding or validating SAML Assertions in > the security runtime, and so I would say it is a required dependency. > For example, the AbstractBindingBuilder has a direct dependency on an > Opensaml import. > > Previously (prior to CXF 2.5 iirc) it was an optional dependency. I > don't see any reason why it should be optional given that it's a core > component of both WSS4J and any SAML functionality in CXF. > > Colm. > > On Fri, Apr 13, 2012 at 12:57 PM, Alessio Soldano <asold...@redhat.com> wrote: >> Hi, >> I've just been running some tests with Apache CXF 2.5.3 tag and noticed >> that I have some failures in the JBossWS integration due to missing >> opensaml classes at runtime. >> AFAICS, the org.opensaml:opensaml dependency is pulled in through WSS4J >> 1.6.5 and I initially assumed it would have been required for WS-Trust / >> STS functionalities only. To be honest, I've been using almost all the >> WS-Security functionalities (except anything related to WS-Trust) of >> 2.5.2 and 2.5.x branch of a couple of weeks ago without that dependency >> available at runtime. >> However, the fix for CXF-4212 now causes the WSS4JInInterceptor to have >> a direct dependency to OpenSAML. When the Spring Bus is being used, any >> attempt to load a bus whose definition includes the WSS4JInInterceptor >> is going to early fail is OpenSaml is not available (as Spring inspects >> beans' classes when the bus is built up). >> Do we really want this behaviour? Are we trying to somehow define >> boundaries for this dependency (for instance considering its size, >> including transitive required sub-dependencies) or this is not perceived >> as an issue at all? >> >> Cheers >> Alessio >> >> -- >> Alessio Soldano >> Web Service Lead, JBoss > > >
-- Alessio Soldano Web Service Lead, JBoss
