camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <>
Subject Re: Camel Exchange Patters
Date Fri, 24 Sep 2010 13:30:19 GMT
On Fri, Sep 24, 2010 at 3:22 PM, Hadrian Zbarcea <> wrote:
> Let's not get there (again). The community agreed already at least twice that this api
is a good abstraction of what we try to do. As any abstraction it has to be properly documented.
If it's not clear enough, that's where I would focus.

I can't recall we agreed this twice or more (since you say at least).
There was a heated debate about the API. And yes I think we should
leave it as it.

On the other hand I am entitled to express my personal view on the API.
And it may be interesting for people in the community to hear from a
committer who was worked 30+ months on Camel, his though of the
Exchange API.

There has been many Camel users who got started with Camel that got
confused / very confused about the API.
So its definitely not good, despite its nature back from the JBI specification.

Competing integration frameworks such as Mule and Spring Integration
has a simpler Exchange API in this area.

And the future of JBI is also dubios. So you may questions where if
someone creates a new integration framework, whether
 he/she will go down the path of JBI and chose to have a getIn and
getOut methods on his/her's "Exchange" type.

> Hadrian
> On Sep 24, 2010, at 8:53 AM, Claus Ibsen wrote:
>> On Fri, Sep 24, 2010 at 2:51 PM,  <> wrote:
>>>> "But the Camel routing engine will automatic handle using IN if there
>>>> is no OUT message."
>>> So this is the magic behind! :-)
>>> I don't remember reading this anywhere previously and I was wondering how data
was flowing from in to out messages.
>>>> Working on IN is just much easier to explain and use for end users.
>>> Honestly it was confusing to me.
>>> Writing something to an "in" message to make it go "out" was really confusing
to me.
>> Yeah the API is not optimal there. We have debated this many times on
>> the dev forums.
>> I personally would remove the IN and OUT and only keen one message.
>>    getMessage()
>> But the current API is kinda stuck due it been there since 1.0 and the
>> old legacy from JBI and whatnot.
>>> *********************************
>>> This message and any attachments (the "message") are confidential and intended
solely for the addressees.
>>> Any unauthorised use or dissemination is prohibited.
>>> Messages are susceptible to alteration.
>>> France Telecom Group shall not be liable for the message if altered, changed
or falsified.
>>> If you are not the intended addressee of this message, please cancel it immediately
and inform the sender.
>>> ********************************
>> --
>> Claus Ibsen
>> Apache Camel Committer
>> Author of Camel in Action:
>> Open Source Integration:
>> Blog:
>> Twitter:

Claus Ibsen
Apache Camel Committer

Author of Camel in Action:
Open Source Integration:

View raw message