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 <qu...@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.ib...@gmail.com >> <mailto:claus.ib...@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 >> <qu...@pronoia-solutions.com <mailto: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 >>>> <mailto: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> >>>> <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>
