One thing you might consider is to use a DTO or "shopping cart" as the body
of your messages to store the state and not use the Exchange itself.
I'm fairly certain Claus isn't at odds with your impulse to use beans
independent of Camel as I think he even writes about that in his book. So
at the
We are actually storing state in the Exchange.
Our routes are boilerplate code that end up invoking a beanref. This
beanref class has no knowledge of Camel - it just has our injected Bean.
Our developers can work on their business logic without having to know
anything about Camel. They can acce
It depends what happens during routing as asynchronouns non blocking
routing can kick in and there can be different threads processing the
exchange along the way.
Your design with using thread local is not a good design.
If you need to store some state then you can store that as properties
on Cam
