camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <>
Subject Re: CamelNamespaceHandler and CAMEL-9570
Date Fri, 11 Nov 2016 18:31:29 GMT

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

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
<> 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 <> wrote:
>> I’ve managed to narrow down the code that causes the issue described in 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,
>> 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
----------------- @davsclaus
Camel in Action 2:

View raw message