Hi,
Comments inline.
Hadrian
On Jul 9, 2009, at 12:54 AM, Claus Ibsen wrote:
On Wed, Jul 8, 2009 at 9:52 PM, Hadrian Zbarcea<hzbar...@gmail.com> wrote:
Hi,
As we approach the 2.0, there is one more hanging issue I would like
addressed, if possible. It's the thorny issue of Faults and Exceptions
that
started in
http://issues.apache.org/activemq/browse/CAMEL-316 (see also the related
nabble thread linked in the issue description).
I am less concerned about how the DefaultExchange is implemented and I
hope
to reach an agreement on what the Exchange api should be (please find the
list of Exchange methods below).
As far as faults/exceptions are concerned, Roman thinks that the whole
concept of in/out/fault/exception is artificial, and only one payload
(message) api should be enough (Roman please correct me if I misinterpret
your position). My opinion is that we *must* distinguish between
persistent
(fault) and transient (exception) errors for the simple reason that they
have different semantics. As Roman correctly points out, faults are more
like outputs, have more of application level semantics and are normally
handled by the client, where exceptions (transient errors) are something
camel could try to recover from, without much knowledge about the
application. I think that the presence of fault in the camel api is not
due
to it being explicitly modeled by jbi and wsdl, as Roman suggests, and
Camel
simply copying that, but it's modeled in Camel for the same reason it's
modeled in jbi and wsdl, to differentiate transient from persistent
errors
in a non ambiguous way.
I am one of the persons that would love the Camel Exchange / Message
API to be a bit simpler. It has a fair shares of methods.
Having listening and discussing with Hadrian on this and doing my own
investigations and whatnot I do belive that Hadrian is absolutely
right when it comes to FAULT. It has a good place in the API. I am +1
on having FAULT as we do now.
The grief I have left is that the IN and OUT. It makes sense to have
them and they provide a good value. However they have a big drawnback
in how they are routed in Camel with the Pipeline processor, that
mimics the pipes and filters EIP. And as a result the OUT will be used
as IN
in the next step in the route. So its not like you can steadily build
up an OUT message on-the-fly during many steps in the route path.
Example
from("direct:start").process(new Processor()).to("log:foo");
a) From
IN = Hello World
OUT = null
b) Processor
IN Hello World
OUT = Bye World
c) Log
IN = Bye World
OUT = null
Yes, from an external observer's perspective, this is precisely what
happens. How we decide to store it, how many fields we need, is an
implementation detail of the DefaultExchange. I don't think the copy from
out/in is too expensive, but I would be ok with having only one field to
store the current message in DefaultExchange (I assume that's what you
propose). However, my question is about what the api should be.
And then the getOut() method that lazy creates a new empty OUT message
is also a pita, as it can lead to people loosing their messages if
they do some System out logging of their own
public void process(Exchange e) {
System.out.println(exchange.getIn());
System.out.println(exchange.getOut());
// boom you lost your message when its routed to next node in route
path, as getOut() created a new empty OUT message that will by used in
the pipes and filters EIP routed with the Pipeline
}
We had this IN OUT discussion a while back and at that time we ended
up with a compromise of having a hasOut() method so you should do, to
be safe:
System.out.println(exchange.getIn());
if (exchange.hasOut()) {
System.out.println(exchange.getOut());
}
Still a pita with the lazy creation IMHO.
The lazyCreate methods are actually deprecated, and imho should be removed
now. This would eliminate the confusion.
If we were to go with only get/setMessage() api, we would still need
methods
(or some ways) to distinguish between the kind of message we are dealing
with (in/out/fault/exception) so we'd only move the problem somewhere
else.
So the question becomes if we leave the api the way it is, or we replace
the
get/setFault apis with get/setOut, in which case we'll need something
like:
boolean isFault();
method in the Message api or keep the hasFault() method on the Exchange.
Good question
If you use OUT instead then we need to add a isFault() on the
org.apache.camel.Message API that
the IN message also implements.
It could make sense to use OUT as well for FAULT.
But how should the API look like to set an OUT as Fault?
Something a like this?
getOut().setBody("Unknown bank account number.");
getOut().setFault(true);
Not quite, I had something like this in mind (there is no setFault()
method):
getOut().setBody(java-lang-Exception-derivedObject);
boolean isFault() {
return getBody() instanceof Exception;
}
Personally I am ok with the limitation not being able to have an out of a
java.lang.Exception type (that would then be a Fault). I can't imagine a
case where an Exception would be an expected out, and in such cases one
could always serialize or wrap it. The fact that the Fault would be an
Exception type would be a camel convention that needs to be followed by all
components.
Another option would be add header HAS_FAULT or something like that, in
which case both the out and the fault could be of any type.
Thoughts?
ExchangePattern getPattern();
void setPattern(ExchangePattern pattern);
Object getProperty(String name);
<T> T getProperty(String name, Class<T> type);
void setProperty(String name, Object value);
Object removeProperty(String name);
Map<String, Object> getProperties();
Message getIn();
void setIn(Message in);
Message getOut();
boolean hasOut();
Message getOut(boolean lazyCreate);
void setOut(Message out);
Message getFault();
boolean hasFault();
Message getFault(boolean lazyCreate);
void removeFault();
// removeFault() is only used in one place
+1 to remove it. You can just do setFault(null) instead. I will fix it
asap.
Exception getException();
<T> T getException(Class<T> type);
void setException(Exception e);
boolean isFailed();
boolean isTransacted();
boolean isRollbackOnly();
CamelContext getContext();
Exchange newInstance();
Exchange copy();
Exchange newCopy(boolean handoverOnCompletion);
void copyFrom(Exchange source);
Endpoint getFromEndpoint();
void setFromEndpoint(Endpoint fromEndpoint);
UnitOfWork getUnitOfWork();
void setUnitOfWork(UnitOfWork unitOfWork);
String getExchangeId();
void setExchangeId(String id);
void addOnCompletion(Synchronization onCompletion);
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
