On Fri, Jun 4, 2010 at 9:41 AM, Willem Jiang <willem.ji...@gmail.com> wrote: > 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. >
Btw first off I want to say fantastic work. This is great news for Camel and Apache that you have found time to help with the OSGi bits here. I think Guillaume is on something here about the type converters. The dynamic world of OSGi collide a bit with the current global type converter standpoint in Camel. I think an OSGiTypeConverterRegistry is needed which keeps track on the loaded type converter from each bundle. So when a bundle is stopped/uninstalled it can remove those associated type converters. One think to do in addition is that the current default type converter has a "hit cache" which means when it have found a given type converter combo, then it cache this. So on next request it can check the cache first instead of trying to resolve a suitable type converter for the combo. This hit cache must then also be maintained if a bundle is uninstalled. But maybe we already got something like this in place. For the other problem, my comments inline. > 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. In normal situations type converters should not override each other. In the core we got the most common converters for XML, String, Numbers, primitive types etc. Then per component have their own component specific converters, such as camel-mina about Mina specific types. So when we see a type converter clash its WARN logged. And we try to fix this in the components by remove the duplicate converter. And this is very seldom this happens. I think its shooting bids with cannons. I think this is fine as is, we should not introduce additional micro management to lock down which converters you want to use. And a type converter is supposed to be "agnostic / generic" so if you want to go from DOM -> String, then if someone overrides this by accident he should be able to convert it as well. Instead of the WARN we could introduce a fail fast instead, so people have to remedy the clash, or offer an option for people to decide: - override (as now) - keep existing (discard the new) - fail Then the Camel end user can decide what should happen >> 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. >> Yeah this is a little Camel contribution to the complexity of the dynamic modularity such as OSGi brings to the table as well :) In fact if people use dynamic EIPs such as Recipient List, Routing Slip etc. they can route to a non deployed component. >> 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 ? >> could be like CASCADE DELETE in SQL, could take down the entire house :) Yeah OSGi brings some news to the table here. Suppose people want to hot update the component. Lets say its just a FTP component that one Camel route will use to upload new files to a remote FTP server. What you could do is to stop that particular route. Update the FTP bundle. And then start the route again. And the other routes in the camelContext could just keep running. Surely this is not an isolated Camel problem. What do people in general want to happen with their apps in OSGi when dependent bundles come and go? Maybe you want a command in the shell, to list the dependent apps which leverage the bundle. So you can tell okay if I stop bundle X what would the effect be? And then a command to for example to stop all those apps. Then you can update/uninstall the bundle. And another command to start those previous apps again. >> Feedback welcomed ! >> >> > > -- Claus Ibsen Apache Camel Committer Author of Camel in Action: http://www.manning.com/ibsen/ Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus
