Thanks for the feedback Gregor -
I have the necessary changes on a local branch - if we decide we want this in
2.21, I can rebase/merge this branch whenever we’re ready.
> On Jan 22, 2018, at 3:42 PM, Gregor Zurowski <gre...@list.zurowski.org> wrote:
>
> 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
