As discussed on another thread today, this one-arg getConfiguration call nails the configuration to the bundle doing the calling, which usually isn’t what you want since it usually isn’t the bundle with the component you’re trying to configure. Use the 2-arg getConfiguration method passing either null, the actual bundle location, or “?”.
Since DS is no longer trying to set the bundle location, null leaves your component vulnerable to something else that does set it to the wrong bundle. Using the actual bundle location means you have to know what it is, but restricts the configuration to that one bundle. “?” lets all bundles see the configuration. david jencks > On Aug 10, 2016, at 8:29 AM, Benson Margulies <[email protected]> wrote: > > Configuration-wise, I have the following code. Logging-wise, I have > pax-exam installing logging, but I will recheck that. > > > org.osgi.service.cm.Configuration workerConf = > configurationAdmin.getConfiguration("com.basistech.ws.worker"); > Dictionary<String, Object> props = new Hashtable<>(); > > Path mainWorkerConfigPath = > Paths.get("../../assemblies/common/configuration/src/main/resources/rosapi/worker-config.yaml"); > Path testEndpointPath = Paths.get("src/test/config/endpoints.yaml"); > > props.put("configurationFilePathname", > mainWorkerConfigPath.toAbsolutePath().toString()); > props.put("endpointsPathname", testEndpointPath.toAbsolutePath().toString()); > > workerConf.setBundleLocation(null); > workerConf.update(props); > > > > On Wed, Aug 10, 2016 at 11:17 AM, David Jencks > <[email protected]> wrote: >>> Configuration Policy: require >> >>> (No Component Configurations) >> >> You need a configuration or change the configuration policy. >> >> Is your minimal container so minimal that it doesn’t include a log service >> or something to collect messages from it? >> >> david jencks >> >>> On Aug 10, 2016, at 8:14 AM, Benson Margulies <[email protected]> wrote: >>> >>> I have some more information. While I still don't know where my log >>> message are going, I turned on the gogo remote shell. According to >>> scr:info, my component is alive. >>> >>> However, I can't obtain a service reference to the service it exports >>> with a plain old ServiceTracker or call to my bundle context. I'd be >>> grateful for any diagnostic advice. >>> >>> >>> scr:info com.basistech.ws.worker.core.config.WorkerConfigurationImpl >>> *** Bundle: rosapi-worker-core (56) >>> Component Description: >>> Name: com.basistech.ws.worker.core.config.WorkerConfigurationImpl >>> Implementation Class: >>> com.basistech.ws.worker.core.config.WorkerConfigurationImpl >>> Default State: enabled >>> Activation: immediate >>> Configuration Policy: require >>> Activate Method: activate >>> Deactivate Method: deactivate >>> Modified Method: - >>> Configuration Pid: >>> [com.basistech.ws.worker.core.config.WorkerConfigurationImpl] >>> Services: >>> com.basistech.ws.worker.core.config.WorkerConfiguration >>> Service Scope: singleton >>> Reference: ConfigurationAdmin >>> Interface Name: org.osgi.service.cm.ConfigurationAdmin >>> Cardinality: 1..1 >>> Policy: static >>> Policy option: reluctant >>> Reference Scope: bundle >>> Component Description Properties: >>> (No Component Configurations) >>> >>> On Wed, Aug 10, 2016 at 10:32 AM, Benson Margulies <[email protected]> >>> wrote: >>>> For unit testing purposes, I'm setting up a minimal container that has >>>> DS/SCR . >>>> >>>> I included: >>>> >>>> <groupId>org.apache.felix</groupId> >>>> <artifactId>org.apache.felix.scr</artifactId> >>>> <version>2.0.6</version> >>>> >>>> I set the framework ds.loglevel property to debug, and I see no sign of >>>> life. >>>> >>>> I'm using standard OSGi DS annotations. >>>> >>>> Can anyone tell me what I'm missing? >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
