You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Claus Ibsen <cl...@gmail.com> on 2018/02/01 14:34:07 UTC

Re: [DISCUSS] Adding a getMessage default methods to the Exchange interface

Hi Quinn

Yeah I think its fine to introduce to 2.x onwards, and as you say it
can help some end users not do the getOut mistake (people really dont
read javadoc anymore, even if its at your fintertips in your java
editor with a cltr + q or whatever key combo you have).



On Tue, Jan 23, 2018 at 12:20 AM, Quinn Stevenson
<qu...@pronoia-solutions.com> wrote:
> 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 <gr...@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 <cl...@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 <cl...@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
>



-- 
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2