cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hadrian Zbarcea <hzbar...@gmail.com>
Subject Re: Are faults errors?
Date Wed, 30 Apr 2008 19:40:39 GMT
I think it's better to continue this discussion on the camel-dev list  
(please don't Reply All).  Thanks to the cxf community for the input.

Hadrian



On Apr 30, 2008, at 1:42 PM, Guillaume Nodet wrote:

> That's a bit of the problem.  Should faults be considered as
> exceptions and interrupt the normal flow or should they considered as
> messages ?   I guess removing them will remove this ambiguity as well,
> because one will have to either use a out message or an error.
>
> As I replied on the other thread, we could also go further and remove
> the exchange, especially if it can not be linked to an invocation
> (like in the wsdl2 model).   For example, if there are multiple outs,
> it may be even easier to just have a Message, with a getter to
> retrieve a Context, and a property to link to the previous message (be
> it the in messge, or anything else related to this message).
>
> On Wed, Apr 30, 2008 at 7:14 PM, Hadrian Zbarcea  
> <hzbarcea@gmail.com> wrote:
>> Hi Bruce,
>>
>> +1 to Hiram's proposal.
>>
>> I cannot speak about the original intentions, but since the idea of  
>> fault
>> is only specific to just a few of the technologies camel supports,  
>> I think
>> having a fault in an exchange could be quite confusing for other  
>> components.
>> I think it should be up to a component to decide what to do with  
>> the faults,
>> camel-cxf in this case.
>>
>> Some expressed the point of view that faults *are* exceptions.  I  
>> am not
>> sure if that meant that they should be of an Exception type, or  
>> that they
>> should be handled as exceptions by the middleware infrastructure.   
>> I later
>> thought they probably meant the former, which is fine.  The out in  
>> the
>> exchange could hold an Exception which may or may not be handled by  
>> camel
>> depending on how the route is defined.
>>
>> My $0.02
>> Hadrian
>>
>>
>>
>> On Apr 30, 2008, at 12:28 PM, Bruce Snyder wrote:
>>
>>
>>> On Wed, Apr 30, 2008 at 9:56 AM, Hiram Chirino <hiram@hiramchirino.com 
>>> >
>> wrote:
>>>
>>>> When I think faults I always think soap faults.  And I think that  
>>>> was
>>>> the main use case behind adding the the fault message in the  
>>>> exchange.
>>>> But the fact is that a fault is just the out message from soap.  A
>>>> soap processor could inspect that out message and notice it's of a
>>>> fault variety.  So my vote is to eliminate the fault message and  
>>>> store
>>>> faults in the out message.
>>>>
>>>> IMO, exceptions thrown by camel processors should be due to  
>>>> internal
>>>> camel errors due to things like not having connectivity or invalid
>>>> configuration etc. etc. Accessing a soap service which returns a  
>>>> fault
>>>> message should not be an exception, it's just a error response that
>>>> needs to get routed.
>>>>
>>>
>>> This discussion immediately makes me think of the fault propagation
>>> rules in WSDL 2.0 which are used to specify the recipient of the  
>>> fault
>>> message. There are three rules in WSDL 2.0:
>>>
>>> 1) Fault replaces message - fault might not be sent to the message
>> originator
>>> 2) Message triggers fault - fault must be sent to the message  
>>> originator
>>> 3) No faults - faults are discarded
>>>
>>> Was there any intention when originally putting faults into Camel to
>>> cover these rules at all? Or is this not a concern at all?
>>>
>>> Bruce
>>> --
>>> perl -e 'print
>> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
>>> );'
>>>
>>> Apache ActiveMQ - http://activemq.org/
>>> Apache Camel - http://activemq.org/camel/
>>> Apache ServiceMix - http://servicemix.org/
>>> Apache Geronimo - http://geronimo.apache.org/
>>>
>>> Blog: http://bruceblog.org/
>>>
>>
>>
>
>
>
> -- 
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/


Mime
View raw message