Hi Yevgeny, I think we never closed the loop here. Do you still see this issue when you just start karaf with resconf feature? if so I think it would be good to open a bug in netconf project specifying if possible steps to reproduce.
> On Oct 14, 2017, at 3:25 PM, [email protected] wrote: > > Hi Luiz, > Thanks for the response but I think beside Karaf problems there is something > in ODL Restconf as well. > After I installed without a problem all bundles and restarted Karaf, I got > > org.osgi.service.blueprint.container.ComponentDefinitionException: Unable to > initialize bean restconfProviderDraft18 > org.osgi.service.blueprint.container.ComponentDefinitionException: > org.osgi.service.blueprint.container.ComponentDefinitionException: Unable to > initialize bean restconfProviderDraft18 > at > org.apache.aries.blueprint.container.ServiceRecipe.createService(ServiceRecipe.java:310) > at > org.apache.aries.blueprint.container.ServiceRecipe.internalGetService(ServiceRecipe.java:252) > at > org.apache.aries.blueprint.container.ServiceRecipe.internalCreate(ServiceRecipe.java:149) > at > org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at > org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88) > at > org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:255) > at > org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:186) > at > org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:724) > at > org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:411) > at > org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:276) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at > org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(ExecutorServiceWrapper.java:106) > at > org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:748) > Caused by: org.osgi.service.blueprint.container.ComponentDefinitionException: > Unable to initialize bean restconfProviderDraft18 > at > org.apache.aries.blueprint.container.BeanRecipe.runBeanProcInit(BeanRecipe.java:738) > at > org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:848) > at > org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:811) > at > org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at > org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88) > at > org.apache.aries.blueprint.di.RefRecipe.internalCreate(RefRecipe.java:62) > at > org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:106) > at > org.apache.aries.blueprint.container.ServiceRecipe.createService(ServiceRecipe.java:285) > ... 21 more > Caused by: > org.opendaylight.netconf.sal.restconf.impl.RestconfDocumentedException: > errors: [RestconfError [error-type: application, error-tag: operation-failed, > error-message: name doesn't exist.]] > at > org.opendaylight.restconf.utils.mapping.RestconfMappingNodeUtil.findNodeInGroupings(RestconfMappingNodeUtil.java:372) > at > org.opendaylight.restconf.utils.mapping.RestconfMappingNodeUtil.addChildOfModuleBySpecificModule(RestconfMappingNodeUtil.java:353) > at > org.opendaylight.restconf.utils.mapping.RestconfMappingNodeUtil.addDeviationList(RestconfMappingNodeUtil.java:198) > at > org.opendaylight.restconf.utils.mapping.RestconfMappingNodeUtil.fillMapByModules(RestconfMappingNodeUtil.java:135) > at > org.opendaylight.restconf.utils.mapping.RestconfMappingNodeUtil.mapModulesByIetfYangLibraryYang(RestconfMappingNodeUtil.java:93) > at > org.opendaylight.restconf.handlers.SchemaContextHandler.onGlobalContextUpdated(SchemaContextHandler.java:63) > at > org.opendaylight.mdsal.dom.broker.osgi.OsgiBundleScanningSchemaService.registerSchemaContextListener(OsgiBundleScanningSchemaService.java:148) > at > org.opendaylight.controller.sal.schema.service.impl.GlobalBundleScanningSchemaServiceImpl.registerSchemaContextListener(GlobalBundleScanningSchemaServiceImpl.java:80) > at > Proxy617c7f6d_e2b5_4492_bda2_f6381d0ec0e9.registerSchemaContextListener(Unknown > Source) > at > Proxy2561774b_7fac_49ed_910b_308feba881f6.registerSchemaContextListener(Unknown > Source) > at > org.opendaylight.restconf.RestConnectorProvider.start(RestConnectorProvider.java:90) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.apache.aries.blueprint.utils.ReflectionUtils.invoke(ReflectionUtils.java:299) > at > org.apache.aries.blueprint.container.BeanRecipe.invoke(BeanRecipe.java:980) > at > org.apache.aries.blueprint.container.BeanRecipe.runBeanProcInit(BeanRecipe.java:736) > ... 29 more > > > What name doesn’t exists? Did I miss something in configuration? > > Thanks, > Yevgeny > > From: Luis Gomez [mailto:[email protected]] > Sent: Thursday, October 12, 2017 7:38 PM > To: Shakhnovich, Yevgeny <[email protected]> > Cc: [email protected] > Subject: Re: [OpenDaylight Discuss] Karaf 4 (Nitrogen) behavior > > I think this is karaf 4 side effect, try to either list all your features in > the config boot file or execute all features at once in console, for example: > > feature:install odl-restconf odl-netconf-mdsal odl-mdsal-apidocs > odl-clustering-test-app odl-netconf-topology > > otherwise bundles may be restarted when you do successive installs. This > behavior cannot be changed AFAIK. > > BR/Luis > > > On Oct 12, 2017, at 11:58 AM, [email protected] wrote: > > Hi, > I need your help. I am porting our project to Nitrogen and have serious > problems with Karaf 4 features. There is something that I don’t understand > there. > On clean Karaf, I first install ODL feature odl-mdsal-apidocs: > > >feature:install odl-mdsal-apidocs > > >list | grep -i -v active > START LEVEL 100 , List Threshold: 50 > ID | State | Lvl | Version | Name > --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > 31 | Resolved | 80 | 4.0.9 | Apache Karaf :: > Diagnostic :: Boot > 183 | Resolved | 80 | 0.7.0 | > config-persister-directory-xml-adapter, Hosts: 185 > 184 | Resolved | 80 | 0.7.0 | > config-persister-file-xml-adapter, Hosts: 185 > > > No problems. Then I want to install a third party bundle > org.apache.mina/mina-core/2.0.9 . If I install it as a bundle, I still don’t > see any problem. > > >bundle:install –s mvn:org.apache.mina/mina-core/2.0.9 > > >list | grep -i -v active > START LEVEL 100 , List Threshold: 50 > ID | State | Lvl | Version | Name > --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > 31 | Resolved | 80 | 4.0.9 | Apache Karaf :: > Diagnostic :: Boot > 183 | Resolved | 80 | 0.7.0 | > config-persister-directory-xml-adapter, Hosts: 185 > 184 | Resolved | 80 | 0.7.0 | > config-persister-file-xml-adapter, Hosts: 185 > > > However, if I wrap it in a feature, I get absolutely different behavior. > > > >feature:install -v my-feature > Adding features: my-feature/[5.0.1.SNAPSHOT, 5.0.1.SNAPSHOT] > Changes to perform: > Region: root > Bundles to install: > mvn:org.apache.mina/mina-core/2.0.9 > Installing bundles: > mvn:org.apache.mina/mina-core/2.0.9 > Stopping bundles: > org.opendaylight.netconf.sal-rest-docgen/1.6.0 > org.opendaylight.netconf.sal-rest-connector/1.6.0 > org.opendaylight.aaa.shiro-act/0.6.0 > org.opendaylight.aaa.shiro/0.6.0 > org.opendaylight.aaa.idmlight/0.6.0 > org.opendaylight.aaa.cert/0.6.0 > org.opendaylight.aaa.encrypt-service/0.6.0 > org.apache.sshd.core/0.14.0 > org.apache.karaf.shell.ssh/4.0.9 > Refreshing bundles: > org.apache.karaf.shell.ssh/4.0.9 (Wired to org.apache.sshd.core/0.14.0 > which is being refreshed) > org.apache.sshd.core/0.14.0 (Should be wired to: > org.apache.mina.core/2.0.9 (through [org.apache.sshd.core/0.14.0] > osgi.wiring.package; > filter:="(&(osgi.wiring.package=org.apache.mina.core.buffer)(version>=2.0.0)(!(version>=3.0.0)))"; > resolution:=optional)) > org.opendaylight.aaa.cert/0.6.0 (Wired to > org.opendaylight.aaa.encrypt-service/0.6.0 which is being refreshed) > org.opendaylight.aaa.encrypt-service/0.6.0 (Wired to > org.apache.sshd.core/0.14.0 which is being refreshed) > org.opendaylight.aaa.idmlight/0.6.0 (Wired to > org.opendaylight.aaa.shiro/0.6.0 which is being refreshed) > org.opendaylight.aaa.shiro/0.6.0 (Wired to > org.opendaylight.aaa.cert/0.6.0 which is being refreshed) > org.opendaylight.aaa.shiro-act/0.6.0 (Wired to > org.opendaylight.aaa.shiro/0.6.0 which is being refreshed) > org.opendaylight.netconf.sal-rest-connector/1.6.0 (Wired to > org.opendaylight.aaa.shiro/0.6.0 which is being refreshed) > org.opendaylight.netconf.sal-rest-docgen/1.6.0 (Wired to > org.opendaylight.aaa.shiro/0.6.0 which is being refreshed) > Starting bundles: > org.apache.mina.core/2.0.9 > Done. > > >list | grep -i -v active > START LEVEL 100 , List Threshold: 50 > ID | State | Lvl | Version | Name > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > 31 | Resolved | 80 | 4.0.9 | Apache Karaf > :: Diagnostic :: Boot > 167 | GracePeriod | 80 | 0.6.0 | ODL :: aaa :: > aaa-cert > 168 | Failure | 80 | 0.6.0 | ODL :: aaa :: > aaa-encrypt-service > 172 | GracePeriod | 80 | 0.6.0 | > org.opendaylight.aaa.aaa-shiro > 183 | Resolved | 80 | 0.7.0 | > config-persister-directory-xml-adapter, Hosts: 185 > 184 | Resolved | 80 | 0.7.0 | > config-persister-file-xml-adapter, Hosts: 185 > 262 | GracePeriod | 80 | 1.6.0 | MD SAL > Restconf Connector > > The “mina” bundle itself is not very important. The same behavior I observed > with some other bundles. I don’t understand why Karaf restarts already > installed bundles simply because I added one more. Why is it important that > the bundle is wrapped in a feature? Can I disable such behavior? > > Thanks, > Yevgeny > > _______________________________________________ > Discuss mailing list > [email protected] > https://lists.opendaylight.org/mailman/listinfo/discuss _______________________________________________ Discuss mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/discuss
