On Jan 15, 2013, at 6:40 AM, Jan Martiška <[email protected]> wrote:
> 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.
Cool. Patch? :-)
> 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.
If we don't MAP the exceptions into the WSDL, but still use the information
from the @Action, I think it would be OK. Definitely something we'd have to
test though and, as you said, more complicated from a patch standpoint.
Dan
>
> 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
>>
>>
--
Daniel Kulp
[email protected] - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
