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]
