Hi I think that dependency stuff was created to ensure Camel would detect which other karaf features it depends upon and then graceful wait for those, instead of fail to startup.
I think it was gnodet whom had this idea and created the initial implementation. Not sure if he or other OSGi guys got some thoughts on this. Just mind that changes to OSGi or blueprint is tricky - as anything can go wrong. I think its worthwhile to give it a go and provide a PR or something for people to help review. And for any changes if being accepted should IMHO only be on master branch. On Fri, Nov 11, 2016 at 4:09 PM, Quinn Stevenson <qu...@pronoia-solutions.com> wrote: > After messing with this for quite a while, I know what is causing CAMEL-9570. > > The CamelNamespaceHandler registers and instance of the > CamelNamespaceHandler$CamelDependenciesFinder as an Aries > ComponentDefinitionRegistryProcessor, which is fine. However, the > CamelDependenciesFinder.process() method forces Blueprint to create objects > which messes-up the internals of the Blueprint context. > > This class shouldn’t be forcing Blueprint to create objects because a > ComponentDefinitionRegistryProcessor is called after the configuration is > parsed, but before any objects are created - it shouldn’t force the creation > of blueprint-managed objects. > > Then net effect of the CamelDependenciesFinder.process() call is the > registration of service references for components, data formats and > languages. In my testing, this isn’t required - I’m not even sure the > services are used. > > I’d like to modify the CamelNamespaceHandler$CamelDependencies finder so it > doesn’t use any blueprint-managed objects. However, this mean that it can’t > process the Camel Context - only the CamelContextFactoryBean. > > Are there any objections to this? If not, I’ll get a PR going. > >> On Nov 8, 2016, at 7:21 AM, Quinn Stevenson <qu...@pronoia-solutions.com> >> wrote: >> >> I’ve managed to narrow down the code that causes the issue described in >> CAMEL-9570 ( https://issues.apache.org/jira/browse/CAMEL-9570 >> <https://issues.apache.org/jira/browse/CAMEL-9570> ). >> >> If I remove the following lines in the CamelNamespaceHandler class >> (parseCamelContextNode method), it corrects issue CAMEL-9570. >> MutablePassThroughMetadata regProcessorFactory = >> context.createMetadata(MutablePassThroughMetadata.class); >> regProcessorFactory.setId(".camelBlueprint.processor.registry.passThrough." >> + contextId); >> regProcessorFactory.setObject(new PassThroughCallable<Object>(new >> CamelDependenciesFinder(contextId, context))); >> >> MutableBeanMetadata regProcessor = >> context.createMetadata(MutableBeanMetadata.class); >> regProcessor.setId(".camelBlueprint.processor.registry." + contextId); >> regProcessor.setRuntimeClass(CamelDependenciesFinder.class); >> regProcessor.setFactoryComponent(regProcessorFactory); >> regProcessor.setFactoryMethod("call"); >> regProcessor.setProcessor(true); >> regProcessor.addDependsOn(".camelBlueprint.processor.bean." + contextId); >> regProcessor.addProperty("blueprintContainer", createRef(context, >> "blueprintContainer")); >> context.getComponentDefinitionRegistry().registerComponentDefinition(regProcessor); >> The problem is, I can’t figure out what the beans created by the metadata >> registered in this code are supposed to do, so I have no idea what the >> effects are of removing this code. >> >> Can someone help me understand what the effects of removing this code would >> be so I can make sure I don’t break anything else? >> >> >> > -- Claus Ibsen ----------------- http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
