Page History

...

This has been moved to its own Wiki page.

Dependency Upgrades

We should upgrade Jetty to 8.x as minimum. And if possible support Jetty 9.x which is in the works.
Currently we are stuck on 7.x due CXF / Karaf etc uses that old version, and thus we have been good citizen to align and use same version.
AMQ is also using older Jetty, but that is easier to upgrade as well.

JMX naming

(+1: cgeer)

We should avoid using the hostname in the JMX MBeans as its better to have a consistent naming that tooling and other parties can rely on. Having the hostname in there just add complexity to the mix. Also Camel may quote the MBean name for the CamelContextMBean and use " " in the mbean name, as the only mbean in there. (will need to double check exactly which mbean it was).

We should consider improve on this.

Remove not used components

We should consider removing

...

The MSV component is never/rarely used, and is causing some issues for cutting releases, due some weird maven issues / download of JARs etc. And the codebase has basically been left unchanged for 5+ years now.

Split camel-cxf into WS and REST

The camel-cxf component has grown too fat and has too many dependencies. People would like to use a light-weight RS. We have already taked talked on Camel @dev about splitting camel-cxf into a WS and RS modules. As well refactor the code-base as there is potential overlap with CXF itself and stuff to be removed/trimmed/optimized etc.

We can have a camel-cfx-core where we can have shared logic if that makes sense.

Remove Spring transaction dependency from JMS component (Removed because SJMS will be non-spring version)

(+1: cgeer)

Refactor the JMS component to remove the dependency on Spring PlatformTransactionManager and replace with JTA TransactionManager.

Old ideas

To be better defined and moved to the section above or removed

...

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.

Remove Spring transaction dependency from JMS component (Removed because SJMS will be non-spring version)

(+1: cgeer)

Refactor the JMS component to remove the dependency on Spring PlatformTransactionManager and replace with JTA TransactionManager.