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
