On Tue, Oct 18, 2016 at 3:18 PM, Paul F Fraser <pa...@a2zliving.com> wrote:
> Hi Benson,
>
> Instead of null
>
> try using configurationAdmin.getConfiguration(pid, "?");
Thanks. This seems to have improved things. Now I can't explain why
the working test worked before, but you can't have everything.
>
> Paul
>
>
> On 18/10/2016 11:46 PM, Benson Margulies wrote:
>>
>> On Tue, Oct 18, 2016 at 8:40 AM, Timothy Ward <tim.w...@paremus.com>
>> wrote:
>>>
>>> How are you creating the configuration?
>>>
>>> Configuration Admin uses the concept of a bundle location to restrict the
>>> visibility of a pid to a particular bundle. This almost always trips people
>>> up when they create the configuration themselves (i.e. in code) as the
>>> “default” methods bind the configuration to the bundle creating it (rarely
>>> what you actually want).
>>
>> I carefully use a 'null' location:
>>
>> configurationAdmin.getConfiguration(pid, null);
>>
>> which I thought was the right recipe.
>>
>> Here's some debug from felix CM:
>>
>> 08:37:00.164 [CM Event Dispatcher (Fire ConfigurationEvent:
>> pid=com.basistech.ws.headless.config)] DEBUG
>> org.apache.felix.configadmin.1.8.10 -
>>
>> [[org.osgi.service.cm.ConfigurationAdmin]]getConfiguration(pid=com.basistech.ws.bus,
>> location=null)
>> 08:37:00.164 [CM Event Dispatcher (Fire ConfigurationEvent:
>> pid=com.basistech.ws.headless.config)] DEBUG
>> org.apache.felix.configadmin.1.8.10 -
>> [[org.osgi.service.cm.ConfigurationAdmin]]No SecurityManager
>> installed; grant CONFIGURE permission on configuration bound to * to
>> bundle
>> /Users/benson/x/rosapi-on-premise/embedded/test/../pre-package/target/bundles/base/rosapi-headless-config-reader-1.4.101-SNAPSHOT.jar
>> 08:37:00.164 [CM Event Dispatcher (Fire ConfigurationEvent:
>> pid=com.basistech.ws.headless.config)] DEBUG
>> org.apache.felix.configadmin.1.8.10 -
>>
>> [[org.osgi.service.cm.ConfigurationAdmin]]createConfiguration(com.basistech.ws.bus,
>> null, null)
>> 08:37:00.165 [CM Event Dispatcher (Fire ConfigurationEvent:
>> pid=com.basistech.ws.headless.config)] DEBUG
>> org.apache.felix.configadmin.1.8.10 -
>>
>> [[org.osgi.service.cm.ConfigurationAdmin]]update(properties={licensePathname=/Users/benson/x/rosapi-on-premise/embedded/test/target/test-config/rosapi/rlp-license.xml})
>> org.apache.felix.configadmin.1.8.10 -
>> [[org.osgi.service.cm.ConfigurationAdmin]]Updating config
>> com.basistech.ws.bus with
>>
>> {licensePathname=/Users/benson/x/rosapi-on-premise/embedded/test/target/test-config/rosapi/rlp-license.xml}
>> 08:37:00.166 [CM Event Dispatcher (Fire ConfigurationEvent:
>> pid=com.basistech.ws.headless.config)] DEBUG
>> org.apache.felix.configadmin.1.8.10 -
>> [[org.osgi.service.cm.ConfigurationAdmin]]No
>> SynchronousConfigurationListeners to send CM_UPDATED event to.
>> 08:37:00.166 [CM Event Dispatcher (Fire ConfigurationEvent:
>> pid=com.basistech.ws.headless.config)] DEBUG
>> org.apache.felix.configadmin.1.8.10 -
>> [[org.osgi.service.cm.ConfigurationAdmin]]Scheduling task Fire
>> ConfigurationEvent: pid=com.basistech.ws.bus
>> 08:37:00.166 [CM Event Dispatcher (Fire ConfigurationEvent:
>> pid=com.basistech.ws.headless.config)] DEBUG
>> org.apache.felix.configadmin.1.8.10 -
>> [[org.osgi.service.cm.ConfigurationAdmin]]Scheduling task Update:
>> pid=com.basistech.ws.bus
>> 08:37:00.166 [CM Event Dispatcher (Fire ConfigurationEvent:
>> pid=com.basistech.ws.headless.config)] DEBUG
>> org.apache.felix.configadmin.1.8.10 -
>>
>> [[org.osgi.service.cm.ConfigurationAdmin]]UpdateConfiguration(com.basistech.ws.bus)
>> scheduled
>>
>>
>>
>>> Also, if your component is not immediate *and* it provides a service then
>>> it will not activate until somebody “gets” the service.
>>
>> Yes, but I have 10 other components stuck waiting for it, so that
>> problem should be solved.
>>
>> While I thank you for advice on diagnosing the problem, I also want to
>> remind you that my original question is how the state is reflected in
>> the DTOs. Solving the actual problem is probably just a matter of log
>> comparison with the working environment.
>>
>>
>>> Regards,
>>>
>>> Tim
>>>
>>>
>>>> On 18 Oct 2016, at 12:47, Benson Margulies <bimargul...@gmail.com>
>>>> wrote:
>>>>
>>>> Here's my puzzle.
>>>>
>>>> I have a set of services that all have unsatisfied references to the
>>>> same thing - a vanilla @Reference to the interface WorkerBusService.
>>>>
>>>> In each case, there is a configuration DTO with an unsatisfied
>>>> reference with name BusConfigured and target null.
>>>>
>>>> WorkerBusService is implemented by an @Component named BusService.
>>>>
>>>> it has a required configuration pid and is _not_ immediate. The
>>>> configuration should be there, I see a log message corresponding to my
>>>> code that updates it into place.
>>>>
>>>> When things time out, BusService has no configuration dtos at all,
>>>> just the description DTO. So, how do I tell why it hasn't started?
>>>> Note that this is an environment where I can't use the shell, so I've
>>>> basically written code that dumps useful output from the introspection
>>>> into a String.
>>>>
>>>> Note that all this works in a slightly different environment, and I'm
>>>> trying to hone these diagnostic tools rather than brute-force a
>>>> comparison to explain the discrepancy.
>>>> _______________________________________________
>>>> OSGi Developer Mail List
>>>> osgi-dev@mail.osgi.org
>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>>
>>> _______________________________________________
>>> OSGi Developer Mail List
>>> osgi-dev@mail.osgi.org
>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>
>> _______________________________________________
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
