Hello
The camel-jonas5 subproject in JOnAS, available:
* In source form via
svn://svn.forge.objectweb.org/svnroot/jonas/sub-projects/camel-jonas5/
* As Maven artifacts via
http://repo1.maven.org/maven2/org/ow2/jonas/camel/
does partially what you're asking for:
* Provides an OSGi Camel service, that you can inject in any other
OSGi bundle using services (we use iPOJO)
* Provides a centralized Registry mechanism
* Provides methods for binding OSGi references into Camel contexts
(for example, the cxfBus argument linking to an OSGi HTTPService
instead of the embedded Jetty container)
* Provides methods for ensuring that all bundles are loaded before
starting any route
Contrairely (PS: that word sounds Frengrish to me) to what its name
indicates, the subproject is NOT dependent on JOnAS. Its only dependency
is iPOJO (itself an Apache project, under the Apache Felix project; that
works on Felix and other OSGi frameworks).
Please check that one out. If you think it's worth being integrated into
the main Camel trunk, we'd be glad to help you. Its current licence is
LGPL anyway :)
Cheers
S. Ali Tokmen
savas-ali.tok...@bull.net
Office: +33 4 76 29 76 19
GSM: +33 66 43 00 555
Bull, Architect of an Open World TM
http://www.bull.com
Guillaume Nodet a écrit :
Actually, for the component factory, the ComponentResolver interface
should be fine ... (forgot about that one).
On Tue, Nov 3, 2009 at 08:49, Guillaume Nodet <gno...@gmail.com> wrote:
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
support.
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
component.
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
registry.
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
available.
I'll try to prototype that this week and i'll keep the list up to date
about that.
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
