camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Willem Jiang <>
Subject Re: [DISCUSS] OSGi improvements and type converters
Date Fri, 04 Jun 2010 07:41:18 GMT
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.


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 !

View raw message