Hi Guillaume,

We have the same type converter override issue in camel which is run within a normal JVM, If we change the class patch we can hit the same issue as running the camel in OSGi platform with different bundle starting up sequence.

I think the type converter is more like a library rather then an OSGi service for Camel. In this case if the bundle of type converter is uninstalled, I think the class not found warning would be enough.

As the type converter is organized by camel context, maybe we can leverage the OSGi package modularity by letting the camelContext descide the type converter in which package it want to load. The short coming of this solution that I can see is user may need to figure out which type converter package that this route may need to use first.

Just my two cents.

Willem

Guillaume Nodet wrote:
I'm working on CAMEL-2693 which main purpose is to use OSGi service
dependencies for components, languages, dataformats.
This will solve a big ordering problem in OSGi (solved at least when
using blueprint) which is the fact that the routes can be started
while components are not available yet, thus leading to startup
failures.
I have things mostly working using:
  * an OSGi activator in camel-core that scans new bundles and
register a ComponentResolver, LanguageResolver and DataFormatResolver
as required for each bundle
  * modification to the OSGi aware camel context to look for
components, languages and dataformats from the osgi registry
  * enhanced the blueprint namespace handler to add osgi service
dependencies to those things that are known to be needed (by browsing
the route definitions)

Now, the last problem I have is around type converters.
It seems type converters are global, which mean that in theory,
registering a new bundle could have a side effect on override another
type converter thus causing a route to fail at the next start.  I
think that's a real problem we want to address.
Also, unless the components / languages / dataformats, type converters
can't be found before actually running the route, so it's kinda
difficult to actually know which ones are needed and if they are
present or not.

Last problem, and this is not specific to type converters is about the
camel context lifecycle wrt components and such.  What if the bundle
of a used component is uninstalled (or stopped even).  Should we stop
the camel context too ?

Feedback welcomed !



Reply via email to