camel-dev mailing list archives

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

Please see my comments in the mail.
Claus Ibsen wrote:
> On Thu, Jul 2, 2009 at 4:21 PM, Guillaume Nodet<gnodet@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.
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.
+1,
let the people register the customer converter himself is a way to have 
the both sides to happy with :)
> 
> 
> 
>> Thoughts ?
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
> 
> 
> 


Mime
View raw message