On Thu, Jul 2, 2009 at 4:21 PM, Guillaume Nodet<gno...@gmail.com> 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. Yeah I would like camel components to be loaded as a single unit that contains whatever it contains - components - languages - data formats - type converters - etc.
Today the type converters kinda stand out as its loaded by itself and it has this classpath annotation scanner. But as you point out it does not work well with the principles of OSGi. So in the future we will change the loading model for camel components. In the short term we can add configuration to disable classpath scanning for type converters. It should still load the default type converters that is define in META-INF/services in a special file. And we can add some configuration to add custom 3rd party type converter classes, eg by refs to spring beans. > > Thoughts ? > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus
