Re: [osgi-dev] Interpreting the ServiceComponentRuntime DTOs

Hi, The difference between null and “?” is that null binds to the first bundle that gets injected with the pid, whereas “?” remains “?” forever. If you have two bundles that use the same pid then null will bite you in the ass, and result in one or other of the bundles (whichever gets injected

Re: [osgi-dev] Interpreting the ServiceComponentRuntime DTOs

On Tue, Oct 18, 2016 at 3:18 PM, Paul F Fraser 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

Re: [osgi-dev] Interpreting the ServiceComponentRuntime DTOs

Perhaps it might help to show the DTO you've dumped here so more eyes can look at it. Sincerely, - Ray On Tue, Oct 18, 2016 at 8:46 AM, Benson Margulies wrote: > On Tue, Oct 18, 2016 at 8:40 AM, Timothy Ward > wrote: > > How are you creating the

Re: [osgi-dev] Interpreting the ServiceComponentRuntime DTOs

On Tue, Oct 18, 2016 at 8:40 AM, Timothy Ward 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

Re: [osgi-dev] Interpreting the ServiceComponentRuntime DTOs

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

[osgi-dev] Interpreting the ServiceComponentRuntime DTOs

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