The spring or blueprint xml based configuration allows you to add interceptors to the bus or to the endpoint etc. But once added, there is no xml way of removing them. That soap action interceptor gets automatically inserted as soon as you use the soap binding. So, writing an interceptor to just reset the soapaction like you did is the simplest workaround.
Regarding the limitation of the fault handling that you had with the addressing, do you mean the oneway case? You are welcome to report issues and also provide patches. thanks. aki 2012/11/23 Paolo Spadafora <[email protected]>: > that's what i just did... > I found not practical to iterate interceptor in chain, find the instance, > then remove it.. it should be possible to remove inside the xml > configuration (we might have different endpoint requirements but shared > instance of custom interceptors). but for now it works. > You are correct, I disabled Addressing because has limited functionality: > messageId duplicate check does not support cluster and restarts, > limitations for soap fault handling if fault is generated in the > interceptor chain and not at entpoint level, does not support WS-I Basic > Profile 2.0, etc. > Basically I end up managing all ws addressing myself. > > Are there any plan to move to WS-I Basic Profile 2.0? > i could help but not before next year. > > thank you > regards, > Paolo > > > > > > 2012/11/23 Aki Yoshida <[email protected]> > >> I am not sure where you are. The action mismatch check happens at the >> ws-addr's MAPAggregator usually. So, you probably disabled >> ws-addressing. But I think it's not a good idea to remove >> SoapActionInInterceptor, as it does other stuff (e.g.., determining >> the binding operation and storing it in the exchange), you will likely >> to break other thing. >> >> If you want to tweak around the action mismatch check, I think you >> would need to write an interceptor to fix the mismatch so that the >> message passes the check. >> >> >> 2012/11/23 wsdev2012 <[email protected]>: >> > Hi, >> > as WS-I basic profile 2.0 requires a check on http header "action" and >> > wsa:Action (must be the same if action is found in ContentType) I need to >> > by-pass the SoapActionInInterceptor and do this >> > check at a later Phase myself. everything works if the action is empty or >> > null. >> > How do I remove this interceptor from the chain? can i do inside spring >> xml >> > config? >> > >> > thank you >> > >> > regards >> > Paolo >> > >> > >> > >> > 2012/11/22 Aki Yoshida-3 [via CXF] < >> [email protected] >> >> >> > >> >> for the wrong "action" case, I think the invalidAddressingHeader is >> >> not the right error code. That is for the "address" value. >> >> If the two actions don't match, the actionMismatch is the right error >> >> code. If the actions match but they are not the right one for the >> >> endpoint, the actionNotSupported is the right one. And I think the >> >> error code is correctly set for these two error cases. The issue that >> >> I mentioned is in the subsequent steps taken after this part. >> >> >> >> For the auto generation of the action, I am not sure the >> >> auto-generation should also apply for the soapaction header. >> >> >> >> >> >> 2012/11/22 wsdev2012 <[hidden email]< >> http://user/SendEmail.jtp?type=node&node=5718978&i=0>>: >> >> >> >> >> >> > beside the case, what do you think on throwing Faut with subcode >> >> > was:InvalidAddressingHeader? >> >> > also, see my second question, if inside wsdl the soapAction is empty >> it >> >> > should fall in default action naming pattern, correct? >> >> > current implementation does not calculate the action from wsdl (but i >> >> see >> >> > the MAP classes do, and wsa:action and http header action attribute >> ctly >> >> > related by specifications ws-addr-soap and ws-addr-wsdl) >> >> > >> >> > Thank you. >> >> > Regards >> >> > Paolo >> >> > >> >> > >> >> > 2012/11/22 Aki Yoshida-3 [via CXF] <[hidden email]< >> http://user/SendEmail.jtp?type=node&node=5718978&i=1>> >> >> >> >> > >> >> >> Hi, >> >> >> I think you are right. There seems to be an issue with the wrong >> >> >> action case and it seems like the fault is not sent back. >> >> >> I'll look into it now. >> >> >> regards, aki >> >> >> >> >> >> 2012/11/22 wsdev2012 <[hidden email]< >> >> http://user/SendEmail.jtp?type=node&node=5718972&i=0>>: >> >> >> >> >> >> >> >> >> > Hi, >> >> >> > I have a web service "wsdl first" with wsdl 1.1 and soap 1.2. >> >> >> > Reading WS-I - R1144 >> >> >> > and SOAP 1.2 Addressing 1.0 Feature >> >> >> > >> >> >> > if the action attribute inside the http header Content-Type is >> >> provided >> >> >> it >> >> >> > has to be processed and validated with the >> soap:operation/@soapAction >> >> >> and >> >> >> > was:Action header. >> >> >> > >> >> >> > but CXF seems to handle faults in a non standard way: >> >> >> > SoapActionInInterceptor throws a general Fault instead of >> >> >> > was:InvalidAddressingHeader if the action attribute from http >> header >> >> >> > Content-Type is not correct (different value from the one inside >> the >> >> >> WSDL >> >> >> > soap:operation/@soapAction being called or provided soap header >> >> >> > "wsa:Action") >> >> >> > >> >> >> > throw new Fault("SOAP_ACTION_MISMATCH", LOG, null, action); >> >> >> > >> >> >> > >> >> >> > I have also another question, if the soap:operation/@soapAction in >> >> the >> >> >> WSDL >> >> >> > is empty shouldn't it be calculated by CXF using the default action >> >> >> patter >> >> >> > as described here >> >> >> > >> http://www.w3.org/TR/2006/CR-ws-addr-wsdl-20060529/#defactionwsdl11 and >> >> >> >> >> > compared to http header action attribute inside Content-Type? >> >> >> > >> >> >> > thank you. >> >> >> > >> >> >> > regards, >> >> >> > Paolo >> >> >> > >> >> >> > >> >> >> > >> >> >> > -- >> >> >> > View this message in context: >> >> >> http://cxf.547215.n5.nabble.com/SOAPAction-tp5718944.html >> >> >> > Sent from the cxf-user mailing list archive at Nabble.com. >> >> >> >> >> >> >> >> >> ------------------------------ >> >> >> If you reply to this email, your message will be added to the >> >> discussion >> >> >> below: >> >> >> >> >> >> >> >> . >> >> >> NAML< >> >> >> http://cxf.547215.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml >> > >> >> >> >> >> >> >> > >> >> > >> >> > >> >> > -- >> >> > Paolo Spadafora >> >> > >> >> > >> >> > >> >> > >> >> > -- >> >> > View this message in context: >> >> http://cxf.547215.n5.nabble.com/SOAPAction-tp5718944p5718974.html >> >> >> >> > Sent from the cxf-user mailing list archive at Nabble.com. >> >> >> >> >> >> ------------------------------ >> >> If you reply to this email, your message will be added to the >> discussion >> >> below: >> >> http://cxf.547215.n5.nabble.com/SOAPAction-tp5718944p5718978.html >> >> To unsubscribe from SOAPAction, click here< >> http://cxf.547215.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5718944&code=cC5zcGFkYWZvcmFAZ21haWwuY29tfDU3MTg5NDR8LTQ1MzQzMDIyNA== >> > >> >> . >> >> NAML< >> http://cxf.547215.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml >> > >> >> >> > >> > >> > >> > -- >> > Paolo Spadafora >> > >> > >> > >> > >> > -- >> > View this message in context: >> http://cxf.547215.n5.nabble.com/SOAPAction-tp5718944p5719012.html >> > Sent from the cxf-user mailing list archive at Nabble.com. >> > > > > -- > Paolo Spadafora
