camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <>
Subject Re: thoughts on the method names for the requestBody and requestBodyAndHeader etc
Date Mon, 20 Apr 2009 04:21:01 GMT
On Sun, Apr 19, 2009 at 8:44 PM, Roman Kalukiewicz
<> wrote:
> Hello Claus,
> You asked for thoughts, so here they are ;)
Great the more the better. This is now you have the chance to
influence the API before 2.0 is settled.
So please reply with any thoughts you have.
The producertemplate is very useful so we want to provide a API that
intuitive and you can use without being in doubt.

> What about totally different approach, that would be a pattern
> parameter instead of a method name. Especially that those methods
> differ only in pattern set on the exchange.
> In fact I believe the best approach would be to have sendMessage()
> method that has pattern as a parameter and is overloaded with versions
> for sending only body, only one header, and a map of headers. Why the
> method name has to show what parameters already clarify?

I see two/three issues with the combined method approach

The method must be delcared to return something. That is a drawback
for InOnly methods where you can use void.
This was confusing in 1.x as people would thing that are doing an
InOut but the have selected a InOnly method but
in the 1.x API it would still return something, and in some of the
older 1.x releases it was the IN payload you sent.

And with the void we get help from the compiler if the end users
things he is doing and InOut and expects an output.

You have to specify the pattern using an enum and thus you need
imports and the method parameters get long
and/or you can use static imports to shorten it. But it all takes time
to setup in the IDE and well ... it just feels
like a drag in 95% if the uses cases where you either use InOnly or InOut.

We should also consider being similar to the other integration
projects in this matter.

Spring Integration uses 2 different method signatures.
Mule as well AFAIR

And now we are talking about this API. What about:

The API in ProducerTemplate have grown to large IMHO. So I also
suggest to reduce it and use specialized methods for the 95% use
And the provide a few fallback methods that you can use for the other 5%.

And we should consider not having copies with both String endpointUri
and Endpoint as the object.
You can always go from Endpoint -> endpointUri so we should consider
removing some of the Endpoint variations.

> Romek
> 2009/4/19 Claus Ibsen <>:
>> Hi
>> Actually I think the naming convention should be:
>> send   = for in only
>> sendWithHeader
>> sendWithHeaders
>> sendAndReceive = for in out
>> sendAndReceiveWithHeader
>> sendAndReceiveWithHeaders
>> Its more intuitive than currently
>> send = for in only
>> request = for in out
>> However what about the "body" method we can do it like
>> sendAndReceiveBody
>> sendAndReceiveBodyWithHeader
>> sendAndReceiveBodyWithHeaders
>> or
>> sendBodyAndReceiveWihHeader
>> sendBodyAndReceiveWithHeaders
>> I prefer the former as its sending a body and receving a body.
>> Any thoughts on this, as we still have time to for this API change
>> before 2.0 is ready for release.
>> However the clock is ticking!!!
>> On Sat, Apr 4, 2009 at 9:20 AM, Claus Ibsen <> wrote:
>>> On Sat, Apr 4, 2009 at 8:38 AM, Ryan Gardner <> wrote:
>>>> The requestBody method makes sense (it requests a body) - but
>>>> "requestBodyAndHeader" and "requestBodyAndHeaders" etc methods make less
>>>> sense - because I'm only requesting one thing (the body).
>>>> maybe "requestBodyWithHeader" makes more sense? for the "sendBodyAndHeader"
>>>> methods, it makes sense because you are sending two things (the body and
>>>> header)
>>>> although, perhaps I'm just going crazy?
>>> No it makes sense. You only get the body as reply.
>>> But to make it consistent the sendBodyAndHeader could also be named as
>>> sendBodyWithHeader.
>>>> Ryan
>>> --
>>> Claus Ibsen
>>> Apache Camel Committer
>>> Open Source Integration:
>>> Blog:
>>> Twitter:
>>> Apache Camel Reference Card:
>> --
>> Claus Ibsen
>> Apache Camel Committer
>> Open Source Integration:
>> Blog:
>> Twitter:
>> Apache Camel Reference Card:

Claus Ibsen
Apache Camel Committer

Open Source Integration:
Apache Camel Reference Card:

View raw message