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 wrote:
>
> Hi
>
> I do really like the idea of having the
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
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
Github user oscerd closed the pull request at:
https://github.com/apache/camel/pull/2181
---
GitHub user objectiser opened a pull request:
https://github.com/apache/camel/pull/2181
CAMEL-12153 Upgrade OpenTracing Java API version to 0.31
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/objectiser/camel otj0.31
GitHub user tdiesler opened a pull request:
https://github.com/apache/camel/pull/2180
[XChange] Add basic support for crypto currency ticker
Resolves CAMEL-12066
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/tdiesler/camel
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