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 > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
