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
<[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]
>
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)[EMAIL PROTECTED]&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/
