Hi,
Please see my comments in the mail.
Claus Ibsen wrote:
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.
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
