felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <ben...@basistech.com>
Subject Re: Bundles needed to use DS/SCR
Date Wed, 10 Aug 2016 15:45:27 GMT
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 <benson@basistech.com> wrote:
> On Wed, Aug 10, 2016 at 11:35 AM, David Jencks
> <david_jencks@yahoo.com.invalid> 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 <benson@basistech.com> 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
>>> <david_jencks@yahoo.com.invalid> 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 <benson@basistech.com>
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 <benson@basistech.com>
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: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Mime
View raw message