opensaml-1.1 dependency [was: svn commit: r663146 - in /cxf/branches/2.0.x-fixes: ...]
Hi Dan, I had to do an manual install of opensaml-1.1.jar in my local repo in order to get a 2.0.x build to work. Is the opensaml stuff up on some obscure maven-repo that I need to add to my ~/.m2/settings.xml? Cheers, Eoghan [EMAIL PROTECTED] wrote: Author: dkulp Date: Wed Jun 4 07:58:47 2008 New Revision: 663146 URL: http://svn.apache.org/viewvc?rev=663146&view=rev Log: Merged revisions 662883 via svnmerge from https://svn.apache.org/repos/asf/cxf/trunk r662883 | dkulp | 2008-06-03 16:55:58 -0400 (Tue, 03 Jun 2008) | 3 lines [CXF-1627] Update to latest wss4j to remove hacks needed to workaround bugs in the older version. Note: wss4j 1.5.4 requires the opensaml library to work at all. Thus, that is added. Modified: cxf/branches/2.0.x-fixes/ (props changed) cxf/branches/2.0.x-fixes/buildtools/src/main/resources/notice-supplements.xml cxf/branches/2.0.x-fixes/rt/ws/security/pom.xml cxf/branches/2.0.x-fixes/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/WSS4JInInterceptor.java cxf/branches/2.0.x-fixes/rt/ws/security/src/test/java/org/apache/cxf/ws/security/wss4j/WSS4JInOutTest.java Propchange: cxf/branches/2.0.x-fixes/ -- Binary property 'svnmerge-integrated' - no diff available. Modified: cxf/branches/2.0.x-fixes/buildtools/src/main/resources/notice-supplements.xml URL: http://svn.apache.org/viewvc/cxf/branches/2.0.x-fixes/buildtools/src/main/resources/notice-supplements.xml?rev=663146&r1=663145&r2=663146&view=diff == --- cxf/branches/2.0.x-fixes/buildtools/src/main/resources/notice-supplements.xml (original) +++ cxf/branches/2.0.x-fixes/buildtools/src/main/resources/notice-supplements.xml Wed Jun 4 07:58:47 2008 @@ -162,7 +162,7 @@ - xml-security + org.apache.santuario xmlsec XML Security @@ -177,6 +177,23 @@ + + + opensaml + opensaml + OpenSAML + +Internet2 +http://www.opensaml.org + + + + The Apache Software License, Version 2.0 + http://www.apache.org/licenses/LICENSE-2.0.txt + + + + xml-apis Modified: cxf/branches/2.0.x-fixes/rt/ws/security/pom.xml URL: http://svn.apache.org/viewvc/cxf/branches/2.0.x-fixes/rt/ws/security/pom.xml?rev=663146&r1=663145&r2=663146&view=diff == --- cxf/branches/2.0.x-fixes/rt/ws/security/pom.xml (original) +++ cxf/branches/2.0.x-fixes/rt/ws/security/pom.xml Wed Jun 4 07:58:47 2008 @@ -60,13 +60,29 @@ org.apache.ws.security wss4j -1.5.2 - - -xml-security -xmlsec -1.3.0 -runtime +1.5.4 + + +axis +axis + + +axis +axis-ant + + +bouncycastle +bcprov-jdk15 + + +xerces +xercesImpl + + +xml-apis +xml-apis + + xalan Modified: cxf/branches/2.0.x-fixes/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/WSS4JInInterceptor.java URL: http://svn.apache.org/viewvc/cxf/branches/2.0.x-fixes/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/WSS4JInInterceptor.java?rev=663146&r1=663145&r2=663146&view=diff == --- cxf/branches/2.0.x-fixes/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/WSS4JInInterceptor.java (original) +++ cxf/branches/2.0.x-fixes/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/WSS4JInInterceptor.java Wed Jun 4 07:58:47 2008 @@ -24,8 +24,8 @@ import java.util.Vector; import java.util.logging.Level; import java.util.logging.Logger; - import javax.security.auth.callback.CallbackHandler; +import javax.xml.namespace.QName; import javax.xml.soap.SOAPBody; import javax.xml.soap.SOAPException; import javax.xml.soap.SOAPMessage; @@ -44,6 +44,8 @@ import org.apache.cxf.phase.Phase; import org.apache.cxf.staxutils.StaxUtils; import org.apache.ws.security.WSConstants; +import org.apache.ws.security.WSSConfig; +import org.apache.ws.security.WSSecurityEngine; import org.apache.ws.security.WSSecurityEngineResult; import org.apache.ws.security.WSSecurityException; import org.apache.ws.security.handler.RequestData; @@ -61,12 +63,18 @@ public static final String TIMESTAMP_RESULT = "wss4j.timestamp.result";
Re: opensaml-1.1 dependency [was: svn commit: r663146 - in /cxf/branches/2.0.x-fixes: ...]
On Jun 6, 2008, at 6:55 AM, Eoghan Glynn wrote: Hi Dan, I had to do an manual install of opensaml-1.1.jar in my local repo in order to get a 2.0.x build to work. That's not good. Is the opensaml stuff up on some obscure maven-repo that I need to add to my ~/.m2/settings.xml? Yea. It's in the webservices groups little repository. It should have worked fine though without modifiying your settings.xml. cruisecontrol was OK with it. Maybe a network glitch or something. Strange. Dan Cheers, Eoghan [EMAIL PROTECTED] wrote: Author: dkulp Date: Wed Jun 4 07:58:47 2008 New Revision: 663146 URL: http://svn.apache.org/viewvc?rev=663146&view=rev Log: Merged revisions 662883 via svnmerge from https://svn.apache.org/repos/asf/cxf/trunk r662883 | dkulp | 2008-06-03 16:55:58 -0400 (Tue, 03 Jun 2008) | 3 lines [CXF-1627] Update to latest wss4j to remove hacks needed to workaround bugs in the older version. Note: wss4j 1.5.4 requires the opensaml library to work at all. Thus, that is added. Modified: cxf/branches/2.0.x-fixes/ (props changed) cxf/branches/2.0.x-fixes/buildtools/src/main/resources/notice- supplements.xml cxf/branches/2.0.x-fixes/rt/ws/security/pom.xml cxf/branches/2.0.x-fixes/rt/ws/security/src/main/java/org/apache/ cxf/ws/security/wss4j/WSS4JInInterceptor.java cxf/branches/2.0.x-fixes/rt/ws/security/src/test/java/org/apache/ cxf/ws/security/wss4j/WSS4JInOutTest.java Propchange: cxf/branches/2.0.x-fixes/ -- Binary property 'svnmerge-integrated' - no diff available. Modified: cxf/branches/2.0.x-fixes/buildtools/src/main/resources/ notice-supplements.xml URL: http://svn.apache.org/viewvc/cxf/branches/2.0.x-fixes/buildtools/src/main/resources/notice-supplements.xml?rev=663146&r1=663145&r2=663146&view=diff = = = = = = = = = = --- cxf/branches/2.0.x-fixes/buildtools/src/main/resources/notice- supplements.xml (original) +++ cxf/branches/2.0.x-fixes/buildtools/src/main/resources/notice- supplements.xml Wed Jun 4 07:58:47 2008 @@ -162,7 +162,7 @@ - xml-security + org.apache.santuario xmlsec XML Security @@ -177,6 +177,23 @@ + + + opensaml + opensaml + OpenSAML + +Internet2 +http://www.opensaml.org + + + + The Apache Software License, Version 2.0 + http://www.apache.org/licenses/LICENSE-2.0.txt + + + + xml-apis Modified: cxf/branches/2.0.x-fixes/rt/ws/security/pom.xml URL: http://svn.apache.org/viewvc/cxf/branches/2.0.x-fixes/rt/ws/security/pom.xml?rev=663146&r1=663145&r2=663146&view=diff = = = = = = = = = = --- cxf/branches/2.0.x-fixes/rt/ws/security/pom.xml (original) +++ cxf/branches/2.0.x-fixes/rt/ws/security/pom.xml Wed Jun 4 07:58:47 2008 @@ -60,13 +60,29 @@ org.apache.ws.security wss4j -1.5.2 - - -xml-security -xmlsec -1.3.0 -runtime +1.5.4 + + +axis +axis + + +axis +axis-ant + + +bouncycastle +bcprov-jdk15 + + +xerces +xercesImpl + + +xml-apis +xml-apis + + xalan Modified: cxf/branches/2.0.x-fixes/rt/ws/security/src/main/java/org/ apache/cxf/ws/security/wss4j/WSS4JInInterceptor.java URL: http://svn.apache.org/viewvc/cxf/branches/2.0.x-fixes/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/WSS4JInInterceptor.java?rev=663146&r1=663145&r2=663146&view=diff = = = = = = = = = = --- cxf/branches/2.0.x-fixes/rt/ws/security/src/main/java/org/ apache/cxf/ws/security/wss4j/WSS4JInInterceptor.java (original) +++ cxf/branches/2.0.x-fixes/rt/ws/security/src/main/java/org/ apache/cxf/ws/security/wss4j/WSS4JInInterceptor.java Wed Jun 4 07:58:47 2008 @@ -24,8 +24,8 @@ import java.util.Vector; import java.util.logging.Level; import java.util.logging.Logger; - import javax.security.auth.callback.CallbackHandler; +import javax.xml.namespace.QName; import javax.xml.soap.SOAPBody; import javax.xml.soap.SOAPException; import javax.xml.soap.SOAPMessage; @@ -44,6 +44,8 @@ import org.apache.cxf.phase.Phase; import org.apache.cxf.staxutils.StaxUtils; import org.apache.ws.security.WSConstants; +import org.apache.ws.
Rationalizing the InterceptorProviders....
I'm trying to dig into CXF-1547 to try and get the "proper" fix in place. Basically, I'm trying to make sure all the InterceptorProviders are properly examined and in a consistent order.We basically have 5 interceptor providers: Endpoint Binding Service Bus Client (client side only) On the server side, they are evaluated in this order: In: bus, endpoint, binding, service Out: endpoint, service, bus, binding Fault: endpoint, binding, service, bus On the client side: In: bus, endpoint, client, binding Out: bus, endpoint, client, binding Fault: endpoint, binding, service, bus Things to note: Client side doesn't look at the Service at all except for faults. We definitely need to fix that. Server side uses different ordering for all three chains. I'd like to make this completely consistent. I want to make it: Server: bus, binding, endpoint, service Client:bus, binding, endpoint, service, client Or: Server: bus, service, endpoint, binding Client: bus, client, service, endpoint, binding Any opinions or objections?Looking through things, I'm leaning toward the second option. It LOOKS like the binding seems to define the most "addAfter" interceptors which cause more work when building the InterceptorChain if they are already in the chain. Thus, putting them at the end may perform the best. I may run some checks to make sure though. In anycase, any thoughts? --- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: Rationalizing the InterceptorProviders....
I'm with ya on the need for consistency here. I honestly have no idea which one will perform best, but I think either options is reasonable. I'll throw one more thing out - we could possibly make Server an InterceptorProvider if we wanted a mirror to the Client InterceptorProvider. I'm not sure if that gives us any needed functionality, but it might make it possible to remove the need for Service to be an InterceptorProvider. Dan On Fri, Jun 6, 2008 at 9:38 AM, Daniel Kulp <[EMAIL PROTECTED]> wrote: > > I'm trying to dig into CXF-1547 to try and get the "proper" fix in place. > Basically, I'm trying to make sure all the InterceptorProviders are > properly examined and in a consistent order.We basically have 5 > interceptor providers: > > Endpoint > Binding > Service > Bus > Client (client side only) > > > On the server side, they are evaluated in this order: > In: bus, endpoint, binding, service > Out: endpoint, service, bus, binding > Fault: endpoint, binding, service, bus > > On the client side: > In: bus, endpoint, client, binding > Out: bus, endpoint, client, binding > Fault: endpoint, binding, service, bus > > > Things to note: > Client side doesn't look at the Service at all except for faults. We > definitely need to fix that. > Server side uses different ordering for all three chains. > > > I'd like to make this completely consistent. I want to make it: > > Server: bus, binding, endpoint, service > Client:bus, binding, endpoint, service, client > > Or: > Server: bus, service, endpoint, binding > Client: bus, client, service, endpoint, binding > > > Any opinions or objections?Looking through things, I'm leaning toward > the second option. It LOOKS like the binding seems to define the most > "addAfter" interceptors which cause more work when building the > InterceptorChain if they are already in the chain. Thus, putting them at > the end may perform the best. I may run some checks to make sure though. > > In anycase, any thoughts? > > --- > Daniel Kulp > [EMAIL PROTECTED] > http://www.dankulp.com/blog > > > > > -- Dan Diephouse http://mulesource.com | http://netzooid.com/blog
Re: Rationalizing the InterceptorProviders....
On Jun 6, 2008, at 12:53 PM, Dan Diephouse wrote: I'm with ya on the need for consistency here. I honestly have no idea which one will perform best, but I think either options is reasonable. The other option is to make in and out symetrical. Example: Server in: bus, service, endpoint, binding Server out: binding, endpoint, service, bus That said, I don't really like it as I think it overly complicates things and is then more to document. I think I'll try the two I listed below and see which performs the best and go with it. I'll throw one more thing out - we could possibly make Server an InterceptorProvider if we wanted a mirror to the Client InterceptorProvider. I'm not sure if that gives us any needed functionality, but it might make it possible to remove the need for Service to be an InterceptorProvider. Hmm... good point about adding to Server. I'll have to think about that a bit more and double check that we even have the Server in all three cases. (example: right now on the client side, we don't have the client when setting up the fault chain. I need to address that.) Dan Dan On Fri, Jun 6, 2008 at 9:38 AM, Daniel Kulp <[EMAIL PROTECTED]> wrote: I'm trying to dig into CXF-1547 to try and get the "proper" fix in place. Basically, I'm trying to make sure all the InterceptorProviders are properly examined and in a consistent order.We basically have 5 interceptor providers: Endpoint Binding Service Bus Client (client side only) On the server side, they are evaluated in this order: In: bus, endpoint, binding, service Out: endpoint, service, bus, binding Fault: endpoint, binding, service, bus On the client side: In: bus, endpoint, client, binding Out: bus, endpoint, client, binding Fault: endpoint, binding, service, bus Things to note: Client side doesn't look at the Service at all except for faults. We definitely need to fix that. Server side uses different ordering for all three chains. I'd like to make this completely consistent. I want to make it: Server: bus, binding, endpoint, service Client:bus, binding, endpoint, service, client Or: Server: bus, service, endpoint, binding Client: bus, client, service, endpoint, binding Any opinions or objections?Looking through things, I'm leaning toward the second option. It LOOKS like the binding seems to define the most "addAfter" interceptors which cause more work when building the InterceptorChain if they are already in the chain. Thus, putting them at the end may perform the best. I may run some checks to make sure though. In anycase, any thoughts? --- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog -- Dan Diephouse http://mulesource.com | http://netzooid.com/blog --- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: Rationalizing the InterceptorProviders....
I would agree with making them consistent (deferring to your judgment of the actual ordering), but one concern I would have would be about backward compatibility--i.e., the interceptors no longer being activated in the order the users are expecting as a result of this switch. Of course, getting the system running right is more important, but just an issue to think about. Glen 2008-06-06 Daniel Kulp wrote: > I'm trying to dig into CXF-1547 to try and get the "proper" fix in > place. Basically, I'm trying to make sure all the > InterceptorProviders are properly examined and in a consistent > order.We basically have 5 interceptor providers: > > Endpoint > Binding > Service > Bus > Client (client side only) > > > On the server side, they are evaluated in this order: > In: bus, endpoint, binding, service > Out: endpoint, service, bus, binding > Fault: endpoint, binding, service, bus > > On the client side: > In: bus, endpoint, client, binding > Out: bus, endpoint, client, binding > Fault: endpoint, binding, service, bus > > > Things to note: > Client side doesn't look at the Service at all except for faults. We > definitely need to fix that. > Server side uses different ordering for all three chains. > > > I'd like to make this completely consistent. I want to make it: > > Server: bus, binding, endpoint, service > Client:bus, binding, endpoint, service, client > > Or: > Server: bus, service, endpoint, binding > Client: bus, client, service, endpoint, binding > > > Any opinions or objections?Looking through things, I'm leaning > toward the second option. It LOOKS like the binding seems to define > the most "addAfter" interceptors which cause more work when building > the InterceptorChain if they are already in the chain. Thus, putting > them at the end may perform the best. I may run some checks to make > sure though. > > In anycase, any thoughts? > > --- > Daniel Kulp > [EMAIL PROTECTED] > http://www.dankulp.com/blog > > > >
