Page History

...

The implementation of DefaultUnitOfWork seems to have transformed itself into a to broad concern where unit of work is doing a bit more work than the transactional aspect that ties to its name.
Maybe this implementation should be named ExchangeContext and we can introduce a simpler UnitOfWork concept. This would also allow us to refactor the SubUnitOfWork into a general parent/child unit of work concept.
However this requires API changes and thus is best kept for Camel 3.0

This is also needed by the refactor of the Message History EIP.

Improvements to ThreadPoolProfile for thread management

...

It would be nice if we have a DSL to compose a number of child EIPs into a single EIP itself. eg a bit like <pipeline>. This would allow people to make it easier to group together a number of EIPs into a single "unit". This allows for example the error handler to redeliver to the composite EIP instead of at the point of failure within the group. There are use-cases where people want to do that. And today the solution is to split this into a new route, which you then disable error handler by setting it to no error handler. And then call the route using the direct endpoint. So instead if you could do <composite> ... stuff goes here </composite> then that would be neater, as you dont have to split into multiple routes. I think there is an old JIRA ticket created about this a long time ago.

Message History EIP

We should make this EIP easier to use for end users, but offering a better public API. And also have a pluggable message store, which filters that can filter what should be store. As well pluggable marshallers so people can marshal data from Exchange into a format the message store can store (BLOB, XML, JSon etc.).