1

I'm wondering if it is possible to leverage what is explaned at par.104.7.5 (Using Multi-Locations) of the osgi enterprise specs using declarative services annotations. Quoting the specs:

It is also possible that Bundles are interested in multiple PIDs for one target service, for this reason they can register multiple PIDs for one service. [...]

A Bundle interested in the host configuration would register a Managed Service with the following properties:

service.pid = [ "com.acme.host", "com.acme.system" ]

The Bundle would be called back for both the com.acme.host and com.acme.system PID and must therefore discriminate between these two cases. This Managed Service therefore would have a callback like:

volatile URL url;
public void updated( Dictionary d ) {
if ( d.get("service.pid").equals("com.acme.host"))
    this.url = new URL( d.get("host"));
if ( d.get("service.pid").equals("com.acme.system"))
   ...
}

I tried with the following syntax:

@Component(
    immediate = true,
    configurationPid = "[com.mycompany.ws.rest,com.mycompany.endpoints]",
    configurationPolicy = ConfigurationPolicy.REQUIRE
) 
public class TestImpl implements Test {
    // ...
}

but this fails. Of course one can get a reference to config admin and browse the configuration based on desired pids but this seems a little bit inelegant to me since in theory it would be possible to delegate that to ds annotations.

Is it possible? What is the correct syntax?

Thank you!

matteo rulli
  • 1,443
  • 2
  • 18
  • 30

3 Answers3

2

I don't believe it is possible by using configurationPid and configurationPolicy values. What I do is the following:

  • Define the service factory pid(s) as service property.
  • Implement the ManagedService interface.

Example:

@Component(property = {Constants.SERVICE_PID + "=com.acme.host", 
                       Constants.SERVICE_PID + "=com.acme.system"})
public class TestComponent implements ManagedService {

    @Override
    public void updated(Dictionary<String, ?> dict) {
    ...
    }

Of course this has the disadvantage that your component is activated even if there is no configuration for it, but you can use two PIDs.

  • Thanks, it works. I think that to solve the problem you highlighted in the last sentence, it is enough to manually register the actual service as soon as TestComponent receives all expected configuration entries from Config Admin, right? – matteo rulli Jul 05 '15 at 20:24
  • Don't know your exact situation, but I assume so. Remember that SCR automatically exports the services you implement, so you probably need a `service=` in your annotation as well to prevent automatic export of the service interface. – Arie van Wijngaarden Jul 06 '15 at 07:02
  • Got it. Thank you very much – matteo rulli Jul 06 '15 at 07:16
  • A couple of remarks. Update is called once for each pid. You can check find which pid in the dictionary using key service.pid. If using a shared bundle pid, make sure your config location is set to null or "?"; If not update might not be called. – Steven Spungin Mar 04 '18 at 15:28
0

Multiple PIDs are supported in the forthcoming DS 1.3 spec. See http://www.osgi.org/Specifications/Drafts for links to download draft Release 6 specs.

BJ Hargrave
  • 9,324
  • 1
  • 19
  • 27
0

Newer versions address the issue...

From: https://osgi.org/specification/osgi.cmpn/7.0.0/service.component.html#org.osgi.service.component.annotations.Component

112.13.4.11 String[] configurationPid default "$" □ The configuration PIDs for the configuration of this Component.

Each value specifies a configuration PID for this Component.

If no value is specified, the name of this Component is used as the configuration PID of this Component.

A special string ("$") can be used to specify the name of the component as a configuration PID. The NAME constant holds this special string. For example:

@Component(configurationPid={"com.acme.system", Component.NAME}) Tools creating a Component Description from this annotation must replace the special string with the actual name of this Component.

See Also The configuration-pid attribute of the component element of a Component Description.

Since 1.2

Victor
  • 3,520
  • 3
  • 38
  • 58