Hello, fellow camel-riders =)

Just recently I came across a heavy use of PT's in production in a outsourcely-designed and non-reviewed bundle with a bunch of facade soap services combining functions from several systems. The typical case was:

* a couple of spring-xml files with usual instantiation and injection of beans and processors and camel contexts,

* plenty of routes starting from cxfEndpoints with contents-based routing ending with processors or beans,

* plenty of routes from direct:something, without any sign of that something in to's in the same context,

* those direct:something endpoints actually getting the payload from some of the above mentioned beans processors.

From my point of view it's a mess... To understand the design and processing logic you need to combine xml contexts/routes with processors and java beans together and additionally track all xml-java transitions (which is a PITA as no single IDE has a good support for both). Generally this feels like a contradiction with the camel way which usually is light and transparent and dry.

The only reasonable production use cases for PT's seem to be

* invocation of external-to-this-context logic implemented with camel and accessible only via some vm or activemq endpoints or

* sending of exchange for alternate processing from several of the error or exception handlers.

Honestly, the first case can be achieved through use of osgi services and the latter with some redesign of routes and exception handling. Both will add to the simplicity and maintainability of the design.

The current idea is to favor maintainability and just ban the use of PT's from production use except those very special cases.

What do You think? Are there other cases when ProducerTemplates are viable of maybe even preferable in the production environment? Should we consider something else before the final judgement?

Regards,

Max