camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Quinn Stevenson <>
Subject Re: CamelNamespaceHandler and CAMEL-9570
Date Fri, 11 Nov 2016 15:09:24 GMT
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?

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message