camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Quinn Stevenson <qu...@pronoia-solutions.com>
Subject Re: CamelNamespaceHandler and CAMEL-9570
Date Mon, 14 Nov 2016 16:43:12 GMT
I created a PR that fixes the issue - hopefully some other OSGi guys will comment on this.

The PR is for CAMEL-9570 -    https://github.com/apache/camel/pull/1269 <https://github.com/apache/camel/pull/1269>

> On Nov 11, 2016, at 1:38 PM, Quinn Stevenson <quinn@pronoia-solutions.com> wrote:
> 
> I can put together a PR, but the more I look at this, the more I think this specific
class isn’t needed.  It’s trying to register service references, but the service references
should already be there IMO.  I know I wouldn’t want Camel to automatically find some service
I wasn’t expecting it to and start using it.  If the service reference isn’t in the Blueprint
context, I don’t think Camel should add it.
> 
> I would really like to hear from some of the other OSGi/Blueprint people on this - get
some opinions.
> 
>> On Nov 11, 2016, at 11:31 AM, Claus Ibsen <claus.ibsen@gmail.com <mailto:claus.ibsen@gmail.com>>
wrote:
>> 
>> 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
>> <quinn@pronoia-solutions.com <mailto:quinn@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 <quinn@pronoia-solutions.com
<mailto:quinn@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>
<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 <http://davsclaus.com/> @davsclaus
>> Camel in Action 2: https://www.manning.com/ibsen2 <https://www.manning.com/ibsen2>


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