We could do that, but it should be up to the client I think. My only point is to discuss and find a way for a predictible behavior in OSGi: i.e. you don't want the converters you depend on to go away or be overriden with another converter from a different application. I think we also have the same problem for components actually: if one route is using a component, there's no guarantee that the component will remain available. What happen if a component bundle is uninstalled when a route is in use ?
I think we need to change the discovery mechanisms in OSGi to use a whiteboard + extender pattern. We have one bundle listening for bundles being installed / uninstalled (or started / stopped). When a bundle is installed / started, we find the component / converters defined in this bundle and create OSGi services for those. Then, when a route is created, we should create the route but have some kind of "dependencies" on the components. So if one component goes away, we should stop the route. Same for converters, but the problem with converters is that we don't know before hand what converter is needed. I guess we need a way for the user to specify which converter it actually need beyond built-in converters or converters defined by the components in use. On Fri, Jul 3, 2009 at 08:21, Christian Schneider<ch...@die-schneider.net> wrote: > How about using osgi services to offer and find converters. You can specifiy > properties on offering and filters on the search to limit what converters > you get. > > Greetings > > Christian > > > Willem Jiang schrieb: >> >> Hi Guillaume, >> >> Before we did some hacking work to let camel load the converters from all >> the bundles, we leverage the camel context OSGi bundle classloader to find >> the converters. In old way, we can configure the which kind of converter we >> want load by importing the converter's package in the camel context OSGi >> bundle. >> >> Now if we want to this feature back, we can revert the change or introduce >> a new class filter mechanism to camel. >> >> Willem >> Guillaume Nodet wrote: >>> >>> I just want to raise a potential problem with the way the camel >>> converters are discovered in OSGi. >>> The main problem i see is that this discovery is global: i.e. camel >>> will discover and use all converters from all installed bundles. >>> I think this could be a problem when you deploy multiple applications: >>> i.e. when you deploy a new application with a few new converters, this >>> could have side effects on another application, eventually breaking >>> it. >>> I wonder if we should have a more static way of configuring converters >>> for a given route. >>> >>> Thoughts ? >>> >> >> > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
