camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Willem Jiang <>
Subject Re: Converter discover in OSGi
Date Fri, 03 Jul 2009 00:12:49 GMT

Please see my comments in the mail.
Claus Ibsen wrote:
> On Thu, Jul 2, 2009 at 4:21 PM, 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.
> 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.
This is a good way for managing the components loading.
But what if there is a data format which is not touch with a component, 
or a user customer converter which is not belongs to any component.
> 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.
We have the same problem in normal using of camel (without OSGi).
If we can get the control of the classpath, we can get the control of 
the converter loading.

> 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.

We could use the OSGi bundle's package importing to help us to do that 
kind of work.

> 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.
let the people register the customer converter himself is a way to have 
the both sides to happy with :)
>> Thoughts ?
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog:
>> ------------------------
>> Open Source SOA

View raw message