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]>: > 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] > 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]>: >> 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}TransportB >> 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]> 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]>: >>>> 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/}Optimiz >>>>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/}Ce >>>>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(Endpoin >>>>tPol >>>>ic >>>> yImpl.java:165) >>>> at >>>> >>>>org.apache.cxf.ws.policy.EndpointPolicyImpl.finalizeConfig(EndpointPo >>>>licy >>>>Im >>>> pl.java:145) >>>> at >>>> >>>>org.apache.cxf.ws.policy.EndpointPolicyImpl.initialize(EndpointPolicy >>>>Impl >>>>.j >>>> ava:141) >>>> at >>>> >>>>org.apache.cxf.ws.policy.PolicyEngineImpl.createEndpointPolicyInfo(Po >>>>licy >>>>En >>>> gineImpl.java:555) >>>> at >>>> >>>>org.apache.cxf.ws.policy.PolicyEngineImpl.getEndpointPolicy(PolicyEng >>>>ineI >>>>mp >>>> l.java:301) >>>> at >>>> >>>>org.apache.cxf.ws.policy.PolicyEngineImpl.getClientEndpointPolicy(Pol >>>>icyE >>>>ng >>>> ineImpl.java:283) >>>> at >>>> >>>>org.apache.cxf.transport.http.policy.PolicyUtils.getClient(PolicyUtil >>>>s.ja >>>>va >>>> :150) >>>> at >>>>org.apache.cxf.transport.http.HTTPConduit.<init>(HTTPConduit.java:308 >>>>) >>>> at >>>> >>>>org.apache.cxf.transport.http.HTTPTransportFactory.getConduit(HTTPTra >>>>nspo >>>>rt >>>> Factory.java:248) >>>> at >>>> >>>>org.apache.cxf.binding.soap.SoapTransportFactory.getConduit(SoapTrans >>>>port >>>>Fa >>>> ctory.java:229) >>>> at >>>> >>>>org.apache.cxf.binding.soap.SoapTransportFactory.getConduit(SoapTrans >>>>port >>>>Fa >>>> ctory.java:236) >>>> at >>>> >>>>org.apache.cxf.endpoint.AbstractConduitSelector.getSelectedConduit(Ab >>>>stra >>>>ct >>>> ConduitSelector.java:88) >>>> at >>>> >>>>org.apache.cxf.endpoint.UpfrontConduitSelector.prepare(UpfrontConduit >>>>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/transport >>>>bind >>>>in >>>> g/" >>>> wsp:Optional="true" /> >>>> <saptrnbnd:OptimizedMimeSerialization >>>> >>>>xmlns:saptrnbnd="http://schemas.xmlsoap.org/ws/2004/09/policy/optimiz >>>>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/poli >>>>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/poli >>>>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/poli >>>>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/Cen >>>>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/";>false >>>></s >>>> apcomhnd:enableCommit> >>>> <sapblock:enableBlocking >>>> >>>>xmlns:sapblock="http://www.sap.com/NW05/soap/features/blocking/";>true >>>></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]> 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]> 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-interceptors >>>>>>-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-ja >>>>>>x-ws >>>>>>-d >>>>>>ispatcher-client-tp5723001.html >>>>>> Sent from the cxf-user mailing list archive at Nabble.com. >>>>> >>>>>-- >>>>>Daniel Kulp >>>>>[email protected] - http://dankulp.com/blog Talend Community Coder - >>>>>http://coders.talend.com >>>>> >>>> >>
