camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <>
Subject Camel in OSGi
Date Tue, 03 Nov 2009 07:49:50 GMT
Yesterday, I've been working again on the blueprint support for camel.
While working on this, I found we're really lacking of some support
for the OSGi dynamism, both with spring-dm support and blueprint
The main problem I see is that components are deployed as bundles, but
there's no dynamism here.  The camel-osgi module has an OSGi activator
which listens to installed bundles and introspect those for new
components.  At the time a camel context is created, if those
components are available, it's fine.  If they're not, the camel
context creation fails.  In addition, if a bundle containing a
component in use is uninstalled or stopped, the camel context is not
stopped, which may lead to the context using an old version of the

In order to solve those issues, I've been thinking about the following:
  * keep camel-osgi module that would contain common osgi support for
both spring-dm and blueprint
  * the camel-osgi module would start an extender to create a
white-board pattern: the extender would listen for new bundles,
introspect those, and register a component factory or language
resolver for each of the language / component defined by this bundle
  * introduce a camel-spring-osgi or camel-spring-dm module to contain
the spring-dm specific part currently in camel-osgi

On point #2, the introduction of a factory for components is required,
because a component is tied to a give camel context, so we need a way
to create new components from a service in the OSGi registry.
The camel-osgi module would be improved to be able to retrieve and
create components from those factories registered in the OSGi

The goal would be to remove some start up problems: it would be very
nice to have the camel context creation deferred until the components
and languages are available in the registry.  Both spring-dm and
blueprint support that, the only problem (which i haven't really
looked into yet) is to know at parsing time which components /
languages are referenced.  This way, we could delegate to spring-dm /
blueprint the fact that we need to wait until all of those are

I'll try to prototype that this week and i'll keep the list up to date
about that.

Guillaume Nodet
Open Source SOA

View raw message