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
