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> 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> >>> 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>
