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
