I see a much dumber mistake here. Sorry for the noise. The test is not pushing the config to the right PID at all.
On Wed, Aug 10, 2016 at 11:43 AM, Benson Margulies <[email protected]> wrote: > On Wed, Aug 10, 2016 at 11:35 AM, David Jencks > <[email protected]> wrote: >> 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 “?”. > > Oh, gosh, I should have caught that. Unfortunately, passing in that > "?" did not change the behavior. Is there also a problem with the > 'setBundleLocation(null)' call I cargo-culted into my code? > > > > g! 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) > >> >> >> 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] >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
