I tried this, and it was pretty simple. I had to modify the Exchange interface and the DefaultExchange class (in camel-core), and the RichExchange class (in camel-scala).
I created https://issues.apache.org/jira/browse/CAMEL-12178 <https://issues.apache.org/jira/browse/CAMEL-12178> for this. > On Jan 17, 2018, at 9:10 AM, Quinn Stevenson <qu...@pronoia-solutions.com> > wrote: > > Thanks Again Claus - > > I’ll create the JIRA ticket, and I’ll run the test suite locally with the > change and see what happens - I’ll let you know what I find out. > > > >> On Jan 17, 2018, at 7:55 AM, 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 >
