You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Ryan Gardner <ry...@gmail.com> on 2009/04/04 08:38:24 UTC
thoughts on the method names for the requestBody and requestBodyAndHeader etc
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 the header)
although, perhaps I'm just going crazy?
Ryan
Re: thoughts on the method names for the requestBody and
requestBodyAndHeader etc
Posted by Claus Ibsen <cl...@gmail.com>.
On Mon, Apr 20, 2009 at 11:29 AM, Roman Kalukiewicz
<ro...@gmail.com> wrote:
> OK Claus, I'm somehow convinced, but what would you say about
>
> sendInOnly()
> sendInOut()
Yeah and we can have a generic send for the remaining 5% use cases,
where you can set the pattern and whatnot.
>
> This way there is no problem at all with understanding what it does
> and the name is short and clear.
Yeah and it also helps bringing the exchange pattern into the light.
>
> Another thing is those headers that I believe should be in overloaded
> signatures and shouldn't be in method names.
Yeah that avoid a bit of confusion as well. However the number of
overloaded methods might explode based on the combo.
But we could reduce it and let people use a processor to setup the
exchange before its sent. This gives them 100% control.
However that usually requires inlined anonym inner class.
Yeah I like your suggestion Roman.
Others any thoughts, yet again its now we have the time to mess with the API.
>
> Roman
>
> 2009/4/20 Claus Ibsen <cl...@gmail.com>:
>> On Sun, Apr 19, 2009 at 8:44 PM, Roman Kalukiewicz
>> <ro...@gmail.com> 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
>>
>> 1)
>> 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.
>>
>>
>> 2)
>> 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.
>>
>> 3)
>> 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:
>>
>> 4)
>> The API in ProducerTemplate have grown to large IMHO. So I also
>> suggest to reduce it and use specialized methods for the 95% use
>> cases.
>> 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 <cl...@gmail.com>:
>>>> 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 <cl...@gmail.com> wrote:
>>>>> On Sat, Apr 4, 2009 at 8:38 AM, Ryan Gardner <ry...@gmail.com> 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 the
>>>>>> 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: http://fusesource.com
>>>>> Blog: http://davsclaus.blogspot.com/
>>>>> Twitter: http://twitter.com/davsclaus
>>>>> Apache Camel Reference Card:
>>>>> http://refcardz.dzone.com/refcardz/enterprise-integration
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Claus Ibsen
>>>> Apache Camel Committer
>>>>
>>>> Open Source Integration: http://fusesource.com
>>>> Blog: http://davsclaus.blogspot.com/
>>>> Twitter: http://twitter.com/davsclaus
>>>> Apache Camel Reference Card:
>>>> http://refcardz.dzone.com/refcardz/enterprise-integration
>>>>
>>>
>>
>>
>>
>> --
>> Claus Ibsen
>> Apache Camel Committer
>>
>> Open Source Integration: http://fusesource.com
>> Blog: http://davsclaus.blogspot.com/
>> Twitter: http://twitter.com/davsclaus
>> Apache Camel Reference Card:
>> http://refcardz.dzone.com/refcardz/enterprise-integration
>>
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Apache Camel Reference Card:
http://refcardz.dzone.com/refcardz/enterprise-integration
Re: thoughts on the method names for the requestBody and
requestBodyAndHeader etc
Posted by Roman Kalukiewicz <ro...@gmail.com>.
OK Claus, I'm somehow convinced, but what would you say about
sendInOnly()
sendInOut()
This way there is no problem at all with understanding what it does
and the name is short and clear.
Another thing is those headers that I believe should be in overloaded
signatures and shouldn't be in method names.
Roman
2009/4/20 Claus Ibsen <cl...@gmail.com>:
> On Sun, Apr 19, 2009 at 8:44 PM, Roman Kalukiewicz
> <ro...@gmail.com> 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
>
> 1)
> 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.
>
>
> 2)
> 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.
>
> 3)
> 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:
>
> 4)
> The API in ProducerTemplate have grown to large IMHO. So I also
> suggest to reduce it and use specialized methods for the 95% use
> cases.
> 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 <cl...@gmail.com>:
>>> 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 <cl...@gmail.com> wrote:
>>>> On Sat, Apr 4, 2009 at 8:38 AM, Ryan Gardner <ry...@gmail.com> 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 the
>>>>> 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: http://fusesource.com
>>>> Blog: http://davsclaus.blogspot.com/
>>>> Twitter: http://twitter.com/davsclaus
>>>> Apache Camel Reference Card:
>>>> http://refcardz.dzone.com/refcardz/enterprise-integration
>>>>
>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> Apache Camel Committer
>>>
>>> Open Source Integration: http://fusesource.com
>>> Blog: http://davsclaus.blogspot.com/
>>> Twitter: http://twitter.com/davsclaus
>>> Apache Camel Reference Card:
>>> http://refcardz.dzone.com/refcardz/enterprise-integration
>>>
>>
>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
> Apache Camel Reference Card:
> http://refcardz.dzone.com/refcardz/enterprise-integration
>
Re: thoughts on the method names for the requestBody and
requestBodyAndHeader etc
Posted by Claus Ibsen <cl...@gmail.com>.
On Sun, Apr 19, 2009 at 8:44 PM, Roman Kalukiewicz
<ro...@gmail.com> 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
1)
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.
2)
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.
3)
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:
4)
The API in ProducerTemplate have grown to large IMHO. So I also
suggest to reduce it and use specialized methods for the 95% use
cases.
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 <cl...@gmail.com>:
>> 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 <cl...@gmail.com> wrote:
>>> On Sat, Apr 4, 2009 at 8:38 AM, Ryan Gardner <ry...@gmail.com> 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 the
>>>> 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: http://fusesource.com
>>> Blog: http://davsclaus.blogspot.com/
>>> Twitter: http://twitter.com/davsclaus
>>> Apache Camel Reference Card:
>>> http://refcardz.dzone.com/refcardz/enterprise-integration
>>>
>>
>>
>>
>> --
>> Claus Ibsen
>> Apache Camel Committer
>>
>> Open Source Integration: http://fusesource.com
>> Blog: http://davsclaus.blogspot.com/
>> Twitter: http://twitter.com/davsclaus
>> Apache Camel Reference Card:
>> http://refcardz.dzone.com/refcardz/enterprise-integration
>>
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Apache Camel Reference Card:
http://refcardz.dzone.com/refcardz/enterprise-integration
Re: thoughts on the method names for the requestBody and
requestBodyAndHeader etc
Posted by Roman Kalukiewicz <ro...@gmail.com>.
Hello Claus,
You asked for thoughts, so here they are ;)
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?
Romek
2009/4/19 Claus Ibsen <cl...@gmail.com>:
> 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 <cl...@gmail.com> wrote:
>> On Sat, Apr 4, 2009 at 8:38 AM, Ryan Gardner <ry...@gmail.com> 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 the
>>> 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: http://fusesource.com
>> Blog: http://davsclaus.blogspot.com/
>> Twitter: http://twitter.com/davsclaus
>> Apache Camel Reference Card:
>> http://refcardz.dzone.com/refcardz/enterprise-integration
>>
>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
> Apache Camel Reference Card:
> http://refcardz.dzone.com/refcardz/enterprise-integration
>
Re: thoughts on the method names for the requestBody and
requestBodyAndHeader etc
Posted by Claus Ibsen <cl...@gmail.com>.
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 <cl...@gmail.com> wrote:
> On Sat, Apr 4, 2009 at 8:38 AM, Ryan Gardner <ry...@gmail.com> 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 the
>> 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: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
> Apache Camel Reference Card:
> http://refcardz.dzone.com/refcardz/enterprise-integration
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Apache Camel Reference Card:
http://refcardz.dzone.com/refcardz/enterprise-integration
Re: thoughts on the method names for the requestBody and
requestBodyAndHeader etc
Posted by Claus Ibsen <cl...@gmail.com>.
On Sat, Apr 4, 2009 at 8:38 AM, Ryan Gardner <ry...@gmail.com> 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 the
> 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: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Apache Camel Reference Card:
http://refcardz.dzone.com/refcardz/enterprise-integration
Re: thoughts on the method names for the requestBody and requestBodyAndHeader etc
Posted by Hadrian Zbarcea <hz...@gmail.com>.
+1
I don't think we need to deprecate it for the 2.0 release. If we have
a good solution let's go with it now.
If not it will need to wait until the next major release.
Hadrian
On Jun 12, 2009, at 12:43 AM, Claus Ibsen wrote:
> On Wed, Jun 10, 2009 at 3:51 PM, Ryan Gardner<ry...@gmail.com>
> wrote:
>> I would suggest @deprecating it for the 2.0 release and work to
>> remove them
>> all by 2.1 (or even if they were all removed, a .t least let users
>> have some
>> time to make the migration)
>
> Well its now we have the time to do it as its a new major release.
> Going for 1.x to 2.0.
> I would *not* like to have a lot of @deprecated methods in a central
> class such as ProducerTemplate
> and having them around until Camel 2.5/3.x comes along. And having to
> add 10x new methods to a ever growing list
> of methods. We already have to many in this class.
>
> So its now or wait till next major release.
>
>
>>
>> On Jun 10, 2009 3:12 AM, "Claus Ibsen" <cl...@gmail.com> wrote:
>>
>> Hi
>>
>> I just did a quick grep for "AndHeader" in unit tests.
>> We use it 554 times. So it will affect many files if we do a rename.
>>
>> On Sat, Apr 4, 2009 at 8:38 AM, Ryan Gardner<ry...@gmail.com>
>> wrote:
>>
>>> The requestBody method makes sense (it requests a body) - but >
>> "requestBodyAndHeader" and "reques...
>> --
>>
>> Claus Ibsen Apache Camel Committer Open Source Integration:
>> http://fusesource.com Blog: http://davs...
>>
>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
Re: thoughts on the method names for the requestBody and
requestBodyAndHeader etc
Posted by Claus Ibsen <cl...@gmail.com>.
On Wed, Jun 10, 2009 at 3:51 PM, Ryan Gardner<ry...@gmail.com> wrote:
> I would suggest @deprecating it for the 2.0 release and work to remove them
> all by 2.1 (or even if they were all removed, a .t least let users have some
> time to make the migration)
Well its now we have the time to do it as its a new major release.
Going for 1.x to 2.0.
I would *not* like to have a lot of @deprecated methods in a central
class such as ProducerTemplate
and having them around until Camel 2.5/3.x comes along. And having to
add 10x new methods to a ever growing list
of methods. We already have to many in this class.
So its now or wait till next major release.
>
> On Jun 10, 2009 3:12 AM, "Claus Ibsen" <cl...@gmail.com> wrote:
>
> Hi
>
> I just did a quick grep for "AndHeader" in unit tests.
> We use it 554 times. So it will affect many files if we do a rename.
>
> On Sat, Apr 4, 2009 at 8:38 AM, Ryan Gardner<ry...@gmail.com> wrote:
>
>> The requestBody method makes sense (it requests a body) - but >
> "requestBodyAndHeader" and "reques...
> --
>
> Claus Ibsen Apache Camel Committer Open Source Integration:
> http://fusesource.com Blog: http://davs...
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: thoughts on the method names for the requestBody and
requestBodyAndHeader etc
Posted by Ryan Gardner <ry...@gmail.com>.
I would suggest @deprecating it for the 2.0 release and work to remove them
all by 2.1 (or even if they were all removed, a .t least let users have some
time to make the migration)
On Jun 10, 2009 3:12 AM, "Claus Ibsen" <cl...@gmail.com> wrote:
Hi
I just did a quick grep for "AndHeader" in unit tests.
We use it 554 times. So it will affect many files if we do a rename.
On Sat, Apr 4, 2009 at 8:38 AM, Ryan Gardner<ry...@gmail.com> wrote:
> The requestBody method makes sense (it requests a body) - but >
"requestBodyAndHeader" and "reques...
--
Claus Ibsen Apache Camel Committer Open Source Integration:
http://fusesource.com Blog: http://davs...
Re: thoughts on the method names for the requestBody and
requestBodyAndHeader etc
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
I just did a quick grep for "AndHeader" in unit tests.
We use it 554 times. So it will affect many files if we do a rename.
On Sat, Apr 4, 2009 at 8:38 AM, Ryan Gardner<ry...@gmail.com> 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 the
> header)
>
> although, perhaps I'm just going crazy?
>
> Ryan
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus