Thanks again Aki. About your point 3 below - so whats the difference between assertor and interceptor? From what I understand so far, it seems that on the client side:
1. I need assertor if I need to add custom policy processing i.e. change my soap request to satisfy policy requirements 2. I need interceptor if I do not need custom policy processing but just need to handle an assertion and mark it as satisfied (i.e. mark assertion as handled without changing soap request) Is this accurate? -----Original Message----- From: Aki Yoshida [mailto:[email protected]] Sent: Friday, February 15, 2013 8:43 AM To: [email protected] Subject: Re: adding interceptors to a dynamic jax-ws dispatcher client Hi Vish, 1. yes. in that case, you might want to just grab the interceptor and put it somewhere in your package. That should work. 3. When you don't need to add a custom policy processing, you don't need it. 4. for the standard ws-security policy assertions like you mentioned, CXF supports them with its rt-ws-security, so you should not have any problems. I think the only problem is for those sap's proprietary policy assertions. For those, you can use the ignorable stuff. regards, aki 2013/2/13 Vishwajit Pantvaidya <[email protected]<mailto:[email protected]>>: > 1. about IgnorablePolicyInterceptorProvider in CXF 2.5.0: we are using older > CXF version included with servicemix - I will try to upgrade that to 2.5.0. > But if that is not an option, then what is the next best thing? Is it okay to > copy the single src java file as is (with the same apache pkg and all copy) > into our source code base? Or can I copy the class file? > 2. ok thanks > 3. yes - the service side is the external service I am trying to call using > the jax-ws dispatch api. Since I am only calling (consuming it), I don't need > the AssertionBuilder right? Things do seem to be working without it. > 4. Sorry for being cryptic here. I was running my same jax-ws client code as > a junit test within Eclipse - there the same code connecting to the same wsdl > endpoint with the same policies strangely worked fine. But I did see the > extra msgs in the console like > "[com.sun.xml.internal.ws.policy.EffectiveAlternativeSelector]selectAlternatives, > WARNING: WSP0075: Policy assertion > "{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}TransportBinding"; > was evaluated as "UNKNOWN"". The msgs seem to indicate that there is a Sun > Java class somewhere in class path which provided the policy alternative. I > was wondering if I could code a similar alternative class that would get > things working? > > Thanks a lot, > > Vish. > > -----Original Message----- > From: Aki Yoshida [mailto:[email protected]] > Sent: Wednesday, February 13, 2013 7:32 AM > To: [email protected]<mailto:[email protected]> > Subject: Re: adding interceptors to a dynamic jax-ws dispatcher client > > Hi Vish, > > good to hear that the error is gone. But you are right and I should have said > that there are 3 options and the third option is to add a policy provider > that implements the specified functionality. > > We can go through your questions one by one. > 1. that class is in cxf-rt-ws-policy-x.x.x.jar and from CXF 2.5.0. > 2. right. In that case, you have a choice of adding a specifc policy provider > to implement the feature so that they get correctly interpreted or implement > an equivalent configuration manually (e.g., in the bus or conduit etc). But > some of the stuff you have in your WSDL are really ignorable. > 3. Is the service side the external web service and your CXF client is > supposed to use the provided WSDL to consume the service, no? In that case, > your client needs it, just as it exploited the ignorable feature there. > 4. I am not sure what you mean by running the test in junit. Which test? > > regards, aki > > 2013/2/13 Vishwajit Pantvaidya > <[email protected]<mailto:[email protected]>>: >> Aki - thanks a lot. That worked pretty easily. >> A few questions: >> 1. I see the IgnorablePolicyInterceptorProvider class in your svn >> link >> - but it is missing from CXF javadoc and also seems to be missing >> from CXF bundle. How do I use this class - do I need to copy it? >> 2. Ignoring is great in the short term - but assuming the wsdl >> policies are accurate and I do not want to ignore them (in the long >> term), then should I be coding a similar interceptor which handles >> the respective Qnames and changes the message appropriately e.g. an >> authentication interceptor can add username/pwd into msg? >> 3. what is the AssertionBuilder needed for (mentioned in >> http://comments.gmane.org/gmane.comp.apache.cxf.user/21774) - is that >> needed on the service side and not on the client side? >> 4. finally, when I ran the same code in a junit env, even without the >> IgnoreablePolicyInterceptorPrivider, it succeeded with messages like: >> [com.sun.xml.internal.ws.policy.EffectiveAlternativeSelector] >> selectAlternatives >> WARNING: WSP0075: Policy assertion >> "{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}Transport >> B >> indin >> g" was evaluated as "UNKNOWN" >> I suppose their is a sun class somewhere in class path which provided >> alternatives. I suppose this would be another way to ignore those policies? >> >> Thanks again, >> >> Vish. >> >> >> On 2/13/13 1:50 AM, "Aki Yoshida" >> <[email protected]<mailto:[email protected]>> wrote: >> >>>your WSDL contains several proprietary policy assertions and CXF is >>>complaining about those assertions. >>> >>>You have two options. >>> >>>1. get an equivalent WSDL without those proprietary assertions 2. use >>>IgnorablePolicyInterceptorProvider to explicitly ignore those >>>assertions. >>>If you go for option 2, you can find an example in and its beans >>>configuration file. >>>http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/policy/src/test/java/ >>>o rg/a >>>pache/cxf/ws/policy/IgnorablePolicyInterceptorProviderTest.java >>> >>>regards, aki >>> >>>2013/2/13 Vishwajit Pantvaidya >>><[email protected]<mailto:[email protected]>>: >>>> Thanks for the help Dan. That moved things a little ahead. I was >>>>able to add the interceptors - but did not know what phase string I >>>>need to have them return. So I debugged the flow in CXF code that >>>>is throwing the error >>>> - and it seems: >>>> 1. the policy in the wsdl has many elements indicated as options >>>>(wsp:Optional=true). But the code in >>>>PolicyEngineImpl.supportsAlternative >>>> seems to be ignoring that setting - it checks only for the variable >>>>named optional, not the wsp:Optional="true" value 2. From the >>>>reason the error is thrown, it seems that if I provide a supported >>>>alternative (Assertor?), the error will not get thrown I.e. >>>> Things may work. But the forum post >>>> http://comments.gmane.org/gmane.comp.apache.cxf.user/21774 from an >>>>earlier user talks about defining AssertionBuilders and >>>>PolicyInterceptorProviders. And my use case seems exactly same as >>>>that described in this post. So do I need to define an alternative >>>>selector or do I need AssertionBuilders / >>>>PolicyInterceptorProviders? >>>> 3. Further, the endpoint does not really seem to be enforcing these >>>>policies - if I edit the wsdl to remome the policies and use the >>>>edited wsdl in my dispatch client call, everything works and I do >>>>get the data from the svc. But when I use the wsdl with the policies, I >>>>get: >>>> >>>> Feb 12, 2013 11:00:59 PM >>>> org.apache.cxf.ws.policy.AssertionBuilderRegistryImpl >>>> handleNoRegisteredBuilder >>>> WARNING: No assertion builder for type >>>> >>>>{http://www.sap.com/webas/710/soap/features/transportbinding/}Optimi >>>>z >>>>edXM >>>>LT >>>> ransfer registered. >>>> Feb 12, 2013 11:00:59 PM >>>> org.apache.cxf.ws.policy.AssertionBuilderRegistryImpl >>>> handleNoRegisteredBuilder >>>> WARNING: No assertion builder for type >>>>{http://www.sap.com/webas/630/soap/features/session/}Session registered. >>>> Feb 12, 2013 11:00:59 PM >>>> org.apache.cxf.ws.policy.AssertionBuilderRegistryImpl >>>> handleNoRegisteredBuilder >>>> WARNING: No assertion builder for type >>>> >>>>{http://www.sap.com/webas/700/soap/features/CentralAdministration/}C >>>>e >>>>ntra >>>>lA >>>> dministration registered. >>>> Feb 12, 2013 11:00:59 PM >>>> org.apache.cxf.ws.policy.AssertionBuilderRegistryImpl >>>> handleNoRegisteredBuilder >>>> WARNING: No assertion builder for type >>>>{http://www.sap.com/NW05/soap/features/commit/}enableCommit registered. >>>> Feb 12, 2013 11:00:59 PM >>>> org.apache.cxf.ws.policy.AssertionBuilderRegistryImpl >>>> handleNoRegisteredBuilder >>>> WARNING: No assertion builder for type >>>>{http://www.sap.com/NW05/soap/features/blocking/}enableBlocking >>>>registered. >>>> Feb 12, 2013 11:00:59 PM >>>> org.apache.cxf.ws.policy.AssertionBuilderRegistryImpl >>>> handleNoRegisteredBuilder >>>> WARNING: No assertion builder for type >>>>{http://www.sap.com/NW05/soap/features/transaction/}required registered. >>>> Feb 12, 2013 11:00:59 PM >>>> org.apache.cxf.ws.policy.AssertionBuilderRegistryImpl >>>> handleNoRegisteredBuilder >>>> WARNING: No assertion builder for type >>>>{http://www.sap.com/NW05/soap/features/wsrm/}enableWSRM registered. >>>> javax.xml.ws.soap.SOAPFaultException: None of the policy >>>>alternatives can be satisfied. >>>> at >>>>org.apache.cxf.jaxws.DispatchImpl.mapException(DispatchImpl.java:285 >>>>) at >>>>org.apache.cxf.jaxws.DispatchImpl.invoke(DispatchImpl.java:388) >>>> at org.apache.cxf.jaxws.DispatchImpl.invoke(DispatchImpl.java:241) >>>> at SoapCaller.send(SoapCaller.java:188) >>>> at SoapCaller.send(SoapCaller.java:184) >>>> at SAPPollerAdapter.main(SAPPollerAdapter.java:70) >>>> Caused by: org.apache.cxf.ws.policy.PolicyException: None of the >>>>policy alternatives can be satisfied. >>>> at >>>> >>>>org.apache.cxf.ws.policy.EndpointPolicyImpl.chooseAlternative(Endpoi >>>>n >>>>tPol >>>>ic >>>> yImpl.java:165) >>>> at >>>> >>>>org.apache.cxf.ws.policy.EndpointPolicyImpl.finalizeConfig(EndpointP >>>>o >>>>licy >>>>Im >>>> pl.java:145) >>>> at >>>> >>>>org.apache.cxf.ws.policy.EndpointPolicyImpl.initialize(EndpointPolic >>>>y >>>>Impl >>>>.j >>>> ava:141) >>>> at >>>> >>>>org.apache.cxf.ws.policy.PolicyEngineImpl.createEndpointPolicyInfo(P >>>>o >>>>licy >>>>En >>>> gineImpl.java:555) >>>> at >>>> >>>>org.apache.cxf.ws.policy.PolicyEngineImpl.getEndpointPolicy(PolicyEn >>>>g >>>>ineI >>>>mp >>>> l.java:301) >>>> at >>>> >>>>org.apache.cxf.ws.policy.PolicyEngineImpl.getClientEndpointPolicy(Po >>>>l >>>>icyE >>>>ng >>>> ineImpl.java:283) >>>> at >>>> >>>>org.apache.cxf.transport.http.policy.PolicyUtils.getClient(PolicyUti >>>>l >>>>s.ja >>>>va >>>> :150) >>>> at >>>>org.apache.cxf.transport.http.HTTPConduit.<init>(HTTPConduit.java:30 >>>>8 >>>>) >>>> at >>>> >>>>org.apache.cxf.transport.http.HTTPTransportFactory.getConduit(HTTPTr >>>>a >>>>nspo >>>>rt >>>> Factory.java:248) >>>> at >>>> >>>>org.apache.cxf.binding.soap.SoapTransportFactory.getConduit(SoapTran >>>>s >>>>port >>>>Fa >>>> ctory.java:229) >>>> at >>>> >>>>org.apache.cxf.binding.soap.SoapTransportFactory.getConduit(SoapTran >>>>s >>>>port >>>>Fa >>>> ctory.java:236) >>>> at >>>> >>>>org.apache.cxf.endpoint.AbstractConduitSelector.getSelectedConduit(A >>>>b >>>>stra >>>>ct >>>> ConduitSelector.java:88) >>>> at >>>> >>>>org.apache.cxf.endpoint.UpfrontConduitSelector.prepare(UpfrontCondui >>>>t >>>>Sele >>>>ct >>>> or.java:61) >>>> at >>>> >>>>org.apache.cxf.endpoint.ClientImpl.prepareConduitSelector(ClientImpl. >>>>java >>>>:8 >>>> 43) >>>> at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:526) >>>> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:461) >>>> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:364) >>>> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:317) >>>> at >>>>org.apache.cxf.endpoint.ClientImpl.invokeWrapped(ClientImpl.java:352 >>>>) at >>>>org.apache.cxf.jaxws.DispatchImpl.invoke(DispatchImpl.java:381) >>>> ... 4 more >>>> >>>> >>>> FYI here is the policy part of the endpoint wsdl: >>>> >>>> <wsp:UsingPolicy wsdl:required="true" /> >>>> <wsp:Policy wsu:Id="BN_BN_binding"> >>>> <saptrnbnd:OptimizedXMLTransfer >>>> uri="http://xml.sap.com/2006/11/esi/esp/binxml"; >>>> >>>>xmlns:saptrnbnd="http://www.sap.com/webas/710/soap/features/transpor >>>>t >>>>bind >>>>in >>>> g/" >>>> wsp:Optional="true" /> >>>> <saptrnbnd:OptimizedMimeSerialization >>>> >>>>xmlns:saptrnbnd="http://schemas.xmlsoap.org/ws/2004/09/policy/optimi >>>>z >>>>edm >>>> imeserialization" >>>> wsp:Optional="true" /> >>>> <wsp:ExactlyOne >>>>xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy";> >>>> <wsp:All> >>>> <sp:TransportBinding >>>> >>>>xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"; >>>> >>>>xmlns:sapsp="http://www.sap.com/webas/630/soap/features/security/pol >>>>i >>>>c >>>> y" >>>> >>>>xmlns:wsa="http://www.w3.org/2005/08/addressing"; >>>> xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512"; >>>> >>>>xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility"; >>>> >>>>xmlns:wsx="http://schemas.xmlsoap.org/ws/2004/09/mex";> >>>> <wsp:Policy> >>>> <sp:TransportToken> >>>> >>>><wsp:Policy> >>>> >>>><sp:HttpsToken> >>>> >>>><wsp:Policy> >>>> >>>> <sp:HttpBasicAuthentication /> >>>> >>>></wsp:Policy> >>>> >>>></sp:HttpsToken> >>>> </wsp:Policy> >>>> </sp:TransportToken> >>>> <sp:AlgorithmSuite> >>>> >>>><wsp:Policy> >>>> >>>><sp:Basic128Rsa15 /> >>>> </wsp:Policy> >>>> </sp:AlgorithmSuite> >>>> <sp:Layout> >>>> >>>><wsp:Policy> >>>> >>>><sp:Strict /> >>>> </wsp:Policy> >>>> </sp:Layout> >>>> </wsp:Policy> >>>> </sp:TransportBinding> >>>> </wsp:All> >>>> <wsp:All> >>>> <sp:TransportBinding >>>> >>>>xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"; >>>> >>>>xmlns:sapsp="http://www.sap.com/webas/630/soap/features/security/pol >>>>i >>>>c >>>> y" >>>> >>>>xmlns:wsa="http://www.w3.org/2005/08/addressing"; >>>> xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512"; >>>> >>>>xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility"; >>>> >>>>xmlns:wsx="http://schemas.xmlsoap.org/ws/2004/09/mex";> >>>> <wsp:Policy> >>>> <sp:TransportToken> >>>> >>>><wsp:Policy> >>>> >>>><sp:HttpsToken> >>>> >>>><wsp:Policy> >>>> >>>> <sp:RequireClientCertificate /> >>>> >>>></wsp:Policy> >>>> >>>></sp:HttpsToken> >>>> </wsp:Policy> >>>> </sp:TransportToken> >>>> <sp:AlgorithmSuite> >>>> >>>><wsp:Policy> >>>> >>>><sp:Basic128Rsa15 /> >>>> </wsp:Policy> >>>> </sp:AlgorithmSuite> >>>> <sp:Layout> >>>> >>>><wsp:Policy> >>>> >>>><sp:Strict /> >>>> </wsp:Policy> >>>> </sp:Layout> >>>> </wsp:Policy> >>>> </sp:TransportBinding> >>>> </wsp:All> >>>> <wsp:All> >>>> <sp:TransportBinding >>>> >>>>xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"; >>>> >>>>xmlns:sapsp="http://www.sap.com/webas/630/soap/features/security/pol >>>>i >>>>c >>>> y" >>>> >>>>xmlns:wsa="http://www.w3.org/2005/08/addressing"; >>>> xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512"; >>>> >>>>xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility"; >>>> >>>>xmlns:wsx="http://schemas.xmlsoap.org/ws/2004/09/mex";> >>>> <wsp:Policy> >>>> <sp:TransportToken> >>>> >>>><wsp:Policy> >>>> >>>><sp:HttpsToken> >>>> >>>><wsp:Policy> >>>> >>>> <sapsp:HTTPSSO2 /> >>>> >>>></wsp:Policy> >>>> >>>></sp:HttpsToken> >>>> </wsp:Policy> >>>> </sp:TransportToken> >>>> <sp:AlgorithmSuite> >>>> >>>><wsp:Policy> >>>> >>>><sp:Basic128Rsa15 /> >>>> </wsp:Policy> >>>> </sp:AlgorithmSuite> >>>> <sp:Layout> >>>> >>>><wsp:Policy> >>>> >>>><sp:Strict /> >>>> </wsp:Policy> >>>> </sp:Layout> >>>> </wsp:Policy> >>>> </sp:TransportBinding> >>>> </wsp:All> >>>> </wsp:ExactlyOne> >>>> <wsaw:UsingAddressing >>>>xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl"; >>>> wsp:Optional="true" /> >>>> </wsp:Policy> >>>> <wsp:Policy wsu:Id="IF_IF_QueryLeadIn"> >>>> <sapsession:Session >>>> >>>>xmlns:sapsession="http://www.sap.com/webas/630/soap/features/session >>>>/ >>>>"> >>>> >>>><sapsession:enableSession>false</sapsession:enableSession> >>>> </sapsession:Session> >>>> <sapcentraladmin:CentralAdministration >>>> >>>>xmlns:sapcentraladmin="http://www.sap.com/webas/700/soap/features/Ce >>>>n >>>>tra >>>> lAdministration/" >>>> wsp:Optional="true"> >>>> >>>><sapcentraladmin:BusinessApplicationID>00163E0327EB1EE1B9A728D061073881 >>>> </sapcentraladmin:BusinessApplicationID> >>>> </sapcentraladmin:CentralAdministration> >>>> </wsp:Policy> >>>> <wsp:Policy wsu:Id="OP_IF_OP_FindByElements"> >>>> <sapcomhnd:enableCommit >>>> >>>>xmlns:sapcomhnd="http://www.sap.com/NW05/soap/features/commit/";>fals >>>>e >>>></s >>>> apcomhnd:enableCommit> >>>> <sapblock:enableBlocking >>>> >>>>xmlns:sapblock="http://www.sap.com/NW05/soap/features/blocking/";>tru >>>>e >>>></s >>>> apblock:enableBlocking> >>>> <saptrhnw05:required >>>> >>>>xmlns:saptrhnw05="http://www.sap.com/NW05/soap/features/transaction/"; >>>>>no >>>> </saptrhnw05:required> >>>> <saprmnw05:enableWSRM >>>>xmlns:saprmnw05="http://www.sap.com/NW05/soap/features/wsrm/";>false >>>> </saprmnw05:enableWSRM> >>>> </wsp:Policy> >>>> >>>> >>>> >>>> Thanks, >>>> >>>> >>>> Vish. >>>> >>>> >>>> On 2/12/13 1:04 PM, "Daniel Kulp" >>>> <[email protected]<mailto:[email protected]>> wrote: >>>> >>>>> >>>>>The Dispatch things are not proxies and thus the >>>>>ClientProxy.getClient call wouldn't work. >>>>> >>>>>I think you need to cast the Dispatch to a CXF specific >>>>>DispatchImpl and call the getClient method on it: >>>>> >>>>>((org.apache.cxf.jaxws.DispatchImpl)dispatch).getClient(); >>>>> >>>>>Hope that helps. >>>>> >>>>> >>>>>Dan >>>>> >>>>> >>>>> >>>>>On Feb 11, 2013, at 7:27 PM, vishp >>>>><[email protected]<mailto:[email protected]>> wrote: >>>>> >>>>>> I am using jax-ws (cxf 2.4.3) dispatch client to invoke a webservice. >>>>>>Since >>>>>> the wsdl specifies some policies, my call fails with the error >>>>>> "javax.xml.ws.soap.SOAPFaultException: None of the policy >>>>>>alternatives can be satisfied". >>>>>> >>>>>> After researching the forums, it seems I need to add an >>>>>>interceptor to handle this situation. Now all the sample code >>>>>>that I have seen to do this is like: >>>>>> ... >>>>>> Client client = ClientProxy.getClient(servicePort); >>>>>> ... >>>>>> >>>>>> My code using the dispatch client is like: >>>>>> >>>>>> Service svc = Service.create(wsdlurl, serviceNs); dispatch = >>>>>> svc.createDispatch(portName, SOAPMessage.class, >>>>>> Service.Mode.MESSAGE); Binding binding = dispatch.getBinding(); >>>>>> List<Handler> handlerChain = binding.getHandlerChain(); >>>>>> handlerChain.add(new SOAPLoggingHandler(logger)); >>>>>> binding.setHandlerChain(handlerChain); >>>>>> >>>>>> I dont know how to get a Client object from the dispatch api so >>>>>>that I can set interceptors like: >>>>>> cxfClient.getInInterceptors().add(...); >>>>>> >>>>>> I found this link in this forum which suggests it should be very easy: >>>>>> >>>>>>http://cxf.547215.n5.nabble.com/adding-features-and-or-interceptor >>>>>>s >>>>>>-to- >>>>>>a- >>>>>>dynamic-jax-ws-dispatcher-client-td3200104.html >>>>>> But after observing the interfaces for these classes and a few >>>>>>others, I am unable to figure it out. Pls help. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> View this message in context: >>>>>>http://cxf.547215.n5.nabble.com/adding-interceptors-to-a-dynamic-j >>>>>>a >>>>>>x-ws >>>>>>-d >>>>>>ispatcher-client-tp5723001.html >>>>>> Sent from the cxf-user mailing list archive at Nabble.com. >>>>> >>>>>-- >>>>>Daniel Kulp >>>>>[email protected]<mailto:[email protected]> - http://dankulp.com/blog Talend >>>>>Community Coder - >>>>>http://coders.talend.com >>>>> >>>> >>
