Hi Dan,
thanks for your response!
I kind of like the idea with CXF specific @FaultAction (we could think of 
naming it somehow else, this might create confusion with 
javax.xml.ws.FaultAction ?). That would resolve my issue and seems usable. I 
was thinking how to implement it, and it seems really easy, just adding the 
annotation, plus something like

FaultAction annotation = fault.getClass().getAnnotation(FaultAction.class);
if(annotation != null) {
    action = annotation.value();
}

into org.apache.cxf.ws.addressing.impl.InternalContextUtils.getAction. It 
doesn't seem to break anything.

Wouldn't the other approach (of not ignoring unchecked exceptions in @Action) 
break JAX-WS spec? I think this approach would require more changes in existing 
stuff (constructing BindingOperationInfo etc.), therefore is more dangerous and 
complicated.

Jan

----- Original Message -----
> From: "Daniel Kulp" <[email protected]>
> To: [email protected], "Jan Martiška" <[email protected]>
> Sent: Monday, January 14, 2013 9:18:47 PM
> Subject: Re: How to set WS-Addressing action for a thrown SoapFault?
> 
> 
> On Jan 14, 2013, at 7:15 AM, Jan Martiška <[email protected]>
> wrote:
> 
> > Hello guys,
> > I am working on WS-Eventing implementation for CXF [1], as I stated
> > some time earlier (it is my master's thesis). However, I need to
> > throw faults from the EventSource service and that introduces a
> > problem. If a service implementation throws an
> > org.apache.cxf.binding.soap.SoapFault, is there any possibility to
> > set the WS-Addressing action associated with this Fault? Setting
> > it through @javax.xml.ws.Action annotation in the webservice's
> > interface definition doesn't seem to help - I think this
> > annotation only affects those exceptions which are mapped into
> > WSDL, that means checked exceptions. However, Fault extends a
> > RuntimeException, so it doesn't map into WSDL and the @Action
> > annotation seems to ignore it.
> 
> Hmm.. not thinking of anything.  However, if you come up with a
> simple test case, I'm wondering how hard it would be to get the
> @Action to not be ignored.   Alternatively, we could create a CXF
> specific @FaultAction or something that could be used to annotate
> the actual exception class to use for this.   Would be fairly
> simple.
> 
> Dan
> 
> 
> > I assume I cannot use checked exceptions, because
> > - according to WS-Eventing specification[2], faults thrown by
> > EventSource / SubscriptionManager should not be mapped into WSDL
> > - the SOAP output needs to be something like [3] (again,
> > specification)
> > 
> > <s12:Envelope>
> >  <s12:Header>
> >    <wsa:Action> *****Action***** </wsa:Action>
> >  </s12:Header>
> >  <s12:Body>
> >    <s12:Fault>
> >      <s12:Code>
> >        <s12:Value>*****Code*****</s12:Value>
> >        <s12:Subcode>
> >          <s12:Value>*****Subcode*****</s12:Value>
> >        </s12:Subcode>
> >      </s12:Code>
> >      <s12:Reason>
> >        <s12:Text xml:lang="en">*****Reason*****</s12:Text>
> >      </s12:Reason>
> >      <s12:Detail>
> >        *****Detail*****
> >      </s12:Detail>
> >    </s12:Fault>
> >  </s12:Body>
> > </s12:Envelope>
> > 
> > which I am not sure if this is possible to accomplish without
> > throwing org.apache.cxf.binding.soap.SoapFault.
> > So far, I have used a bit of a hack, introducing an additional
> > SoapInterceptor [4], which does the work of setting the WSA
> > action, when a SoapFault is thrown. But that hack introduces
> > unwanted complexity and code unclarity (I also need a new Feature
> > to apply this interceptor). I would like to get rid of that, if it
> > is possible to do it a better way, preferably without too much CXF
> > internal API.
> > 
> > Thanks for any suggestions (if you have any) :)
> > Jan
> > (from Red Hat)
> > 
> > [1]
> > https://github.com/jmartisk/cxf/tree/jmartisk-devel/rt/ws/eventing
> > [2] http://www.w3.org/TR/ws-eventing/
> > [3] http://www.w3.org/TR/ws-eventing/#Faults
> > [4]
> > https://github.com/jmartisk/cxf/blob/jmartisk-devel/rt/ws/eventing/src/main/java/org/apache/cxf/ws/eventing/shared/faulthandling/EventingFaultHandler.java
> 
> --
> Daniel Kulp
> [email protected] - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
> 
> 

Reply via email to