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
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.
>
> 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);
>
> 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
