Hi,
I fully agree that changing the getMessage/setMessage API will be
beneficial for most Camel users. Therefore +1 for changing this in
Camel 2.21 already. Thanks @Quinn for binging this up.
Thanks,
Gregor
On Wed, Jan 17, 2018 at 3:55 PM, Claus Ibsen <claus.ib...@gmail.com> wrote:
> Hi
>
> I do really like the idea of having the getMessage/setMessage APIs
> that end users should use in 99% of the use-case, and then leave the
> IN vs OUT for the special cases, or potential component developers.
>
> I do think you should log a JIRA ticket. And surely get its done for
> 3.0, but I would like to hear more feedback from the community whether
> they would like to see this added to Camel 2.21 as well? I can't think
> that eg simple language and some of those dynamic scripting languages
> could have problems with this change, but we should run the unit test
> suite of core / spring and other important components, just in case.
>
>
> On Wed, Jan 17, 2018 at 3:27 PM, Quinn Stevenson
> <qu...@pronoia-solutions.com> wrote:
>> Thanks Claus -
>>
>> I’ve used the IN/OUT thing a couple of times to my advantage, but most of
>> the time it just seems to get in the way, which is why I was suggesting this
>> API change. I like having the flexibility of the IN/OUT paradigm but most
>> of the time, I don’t really want to have to think about it.
>>
>> I hadn’t considered a setMessage - I’ve never had to use that method before
>> so I didn’t thing about it as well.
>>
>> I’m fine with waiting for 3.0 for this type of change - I’ll just keep
>> teaching my customers the “hasOut() ? getOut() : getIn()” technique :-)
>>
>>> On Jan 17, 2018, at 1:38 AM, Claus Ibsen <claus.ib...@gmail.com> wrote:
>>>
>>> Hi
>>>
>>> The IN vs OUT thing has probably manifested itself into Camel as its
>>> been there from the very beginning (API inspired by JBI when James
>>> created it).
>>>
>>> There is only one implementation of the Exchange interface,
>>> DefaultExchange and therefore API changes on it is "less risky" as it
>>> used to be in 1.x when we had multiple implementations. But the
>>> camel-scala module may barf as it has some RichExchange stuff, but
>>> usually you can add similar methods there to make it compile. Also
>>> camel-scala is deprecated. And as such we wouldn't need to have these
>>> methods as "default" interface methods but can be added as normal
>>> methods.
>>>
>>> Should we also have a setMessage method as well.
>>>
>>> This kind of API change is something that is a good thing for Camel 3.0.
>>> If we keep altering 2.x then we wont get to a 3.0 ;)
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Jan 16, 2018 at 5:04 PM, Quinn Stevenson
>>> <qu...@pronoia-solutions.com> wrote:
>>>> I’d like to add the following to the Exchange interface.
>>>>
>>>> default Message getMessage() {
>>>> return hasOut() ? getOut() : getIn();
>>>> }
>>>>
>>>> default <T> T getMessage(Class<T> type) {
>>>> return hasOut() ? getOut(type) : getIn(type);
>>>> }
>>>>
>>>> I’ve run a across the same error about a dozen times now with customers
>>>> (where the work on the wrong message), and a simple addition to the
>>>> Exchange interface would really help.
>>>>
>>>> Since this would change a core interface in Camel, I wanted to get some
>>>> feedback before I made the change.
>>>>
>>>> Thoughts?
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> -----------------
>>> http://davsclaus.com @davsclaus
>>> Camel in Action 2: https://www.manning.com/ibsen2
>>
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
