On Thu, Jul 9, 2009 at 7:25 PM, Hadrian Zbarcea<hzbar...@gmail.com> wrote: > Ah, your proposal is a variation of the first one, where isFault and > setFault() are Message methods, not Exchange. I am fine with that too. Not > sure about the boolean argument for setFault, but that's a detail. Why > would somebody invoke: > message.setFault(false); > > 3. > Exchange interface > Message getOut(); > void setOut(Message out); > > Message interface > boolean hasFault(); > void setFault(); // or > void setFault(boolean value); > > I am ok with all three api versions proposed so far. I guess [3] is clearer > more intuitive. Yeah #3 is nice, makes Exchange has less methods.
I think the names should be boolean isFault() void setFault() Yeah I do not think people should call setFault(false) or later want to change an existing OUT message from fault to out or vice versa. But is it confusing with a setter that dont accept parameters, does it violate the bean spec? > > Thanks > Hadrian > > > On Jul 9, 2009, at 1:11 PM, James Strachan wrote: > >> 2009/7/9 Hadrian Zbarcea <hzbar...@gmail.com>: >>> >>> That is *only one* of getOut() and getFault() would return a non null >>> object >>> depending on the CAMEL_FAULT header being present. >>> setOut() and setFault() would (re)set the CAMEL_FAULT header as needed. >>> OUT >>> and FAULT are mutually exclusive. >> >> Which is why I'm thinking we just have one propery, "out" which the >> message has an isFault() / setFault(boolean) property on it. >> >> >> -- >> James >> ------- >> http://macstrac.blogspot.com/ >> >> Open Source Integration >> http://fusesource.com/ > > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus
