camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Trenaman <>
Subject Re: Camel, OSGI and container wide Camel route lookups
Date Mon, 09 Aug 2010 19:37:58 GMT
Hi Christian,

As far as I know, camel contexts are intended to be isolated, so detecting routes in other
contexts will not work. 

I recently did some work on a similar use-case by wiring in dynamic 'extension' processors
using OSGi registry lookups: it worked quite well! However, I would caution against making
things too dynamic. In my OSGi case, extension points that are temporarily not present were
simply not executed: so, if a country-specific bundle was taken down or restarted, then there
was a chance that important country-specific processing would be skipped, albeit for a brief
period. In this case, you really need to adorn the incoming exchange with a set of mandatory
extension points that must be processed for the message to be considered successfully processed.
That way, the route can complain loud if a mandatory extension point is not present. 

Hope that makes sense!

----- Original Message -----
From: Christian Mueller <>
To: <>
Sent: Mon Aug 09 13:02:31 2010
Subject: Camel, OSGI and container wide Camel route lookups

Hello list!

The question: It is possible to discover a Camel route which is deployed in
another OSGI bundle like in the following code snippet:?


The context: We are using Camel 2.2.0-fuse-02-00 inside FUSE ESB
4.2.0-fuse-02-00. We only use Camel for our integration requirements (no
JBI). Our first integration solution contains approximate 15+ OSGI bundles.
Each OSGI bundle consists of one Camel context. This means we will deploy
15+ different Camel context.

Because we have to define standardized integration solutions for multiple
countries (with its country specificities), we plan to define our routes in
a template style where in the common route (the template) we define the
common part (which is equal in every country). In this common route, we will
define "extension" points where we will lookup the country specific
Processors. If they exists, we will execute they. If not, we will fallback
to the common processing. For a better understanding, a sample (really
"dynamic") route could looks like:

    .bean("orderEntry", "validate")
    .process(new ExtensionDiscoverProcessor("direct:preProcessOrderEntry"))
// country specific pre processing - if defined
    .process(new ExtensionDiscoverProcessor("direct:processOrderEntry")) //
country specific processing - if defined
    .process(new ExtensionDiscoverProcessor("direct:postProcessOrderEntry"))
// country specific post processing - if defined
    .bean("orderEntry", "audit")

public class ExtensionDiscoverProcessor implements Processor,
InitializingBean {
	private String baseEndpointUri;

	public ExtensionDiscoverProcessor(String baseEndpointUri) {
		this.baseEndpointUri= baseEndpointUri;

	public void process(Exchange exchange) throws Exception {
		String countryId = exchange.getIn().getHeader("COUNTRY_ID", String.class);
		String extensionEndpointUri = baseEndpointUri + rbuId;
		Endpoint endpoint =
		if (endpoint == null) {
			if (log.isDebugEnabled()) {
				log.debug("Extension endpoint '" + extensionEndpointUri + " doesn't
exist. Use base endpoint '" + baseEndpointUri + "'.");
			endpoint = exchange.getContext().hasEndpoint(baseEndpointUri);
			if (endpoint == null) {
				throw new IllegalArgumentException("Missing mandatory endpoint '" +
baseEndpointUri + "'");

If it's not possible, do you have an advice for an alternative?
I hope this was understandable... :o)

Thanks in advanced for your time and help,
View this message in context:
Sent from the Camel - Users mailing list archive at
View raw message