Thanks a lot for the clarification. I was wrongly assuming that the connection is made by leveraging the SERVICE_PID property of the component, which is now no longer set by default by the maven-scr-plugin (https://issues.apache.org/jira/browse/FELIX-5304 <https://issues.apache.org/jira/browse/FELIX-5304>). But the actual logic is vice-versa, so the configuration PID determines the automatically set SERVICE_PID not the other way round. Thanks a lot for the explanation. Konrad
> On 20 Jul 2016, at 18:18, Carsten Ziegeler <[email protected]> wrote: > >> Hi Carsten, >> I am just wondering because you said the service PID is an implementation >> detail and being generated automatically by DS (in case the service has been >> started by DS), if we can always rely on the PID being the component's class >> name for all Felix version's in the future. > > The component xml for a DS component has an attribute for a PID, so a > developer can specify a PID. If not specified it defaults to the > component name, again something the developer can specify. If that one > is not defined by the developer, it falls back to the class name. > > So, yes, the default is the class name. > >> I just don't know how the connection is made between the service and its >> configuration in case the service is already running (and just a new >> configuration should be bound). > > It's based on the PID, DS looks up the configuration using the PID(s) > specified in the component XML. > >> In case I want to deploy a configuration through the OSGi installer, I want >> to make sure it gets bound to the right component. > > As you're the developer of the component, you know it's PID, as its you > who defines it in the first place. > >> >> Have you any reference about the format of the PID which must be used here? > > Usually it uses reverse domain names and class names of implementations > are pretty good PIDs as they are mostly unique - unless it happens that > you deploy two different bundles which happen to have the same > implementation class. That's why the below text states to use the > bundle's identifier. But using bundle Id is of course problematic as you > don't know it up front. Therefore being pragmatic and using class names > usually does the trick. > > Or in short, nothing changes for how we develop components or configure > them. The only thing we have to check where our code is using the > SERVICE_PID, if that usage is ok. > > Carsten > >> In OSGi Core 6.0.0, 10.1.15.106 it just says >> >> public static final String SERVICE_PID = "service.pid" >> Service property identifying a service's persistent identifier. >> This property may be supplied in the properties Dictionary object passed to >> the >> BundleContext.registerService method. The value of this property must be of >> type String, String[], >> or Collection of String. >> A service's persistent identifier uniquely identifies the service and >> persists across multiple Framework >> invocations. >> By convention, every bundle has its own unique namespace, starting with the >> bundle's identifier >> (see Bundle.getBundleId()) and followed by a dot (.). A bundle may use this >> as the prefix of the persistent >> identifiers for the services it registers. >> >> >> Konrad >> >>> On 20 Jul 2016, at 17:42, Carsten Ziegeler <[email protected]> wrote: >>> >>>> What about usage of PIDs when providing configurations through the >>>> repository (as sling:OsgiConfig resources or configuration files as >>>> described in >>>> https://sling.apache.org/documentation/bundles/configuration-installer-factory.html >>>> >>>> <https://sling.apache.org/documentation/bundles/configuration-installer-factory.html>) >>>> for the OSGi installer. The resource names are supposed to be (at least >>>> starting with the) PID, e.g. mentioned in >>>> https://sling.apache.org/documentation/bundles/osgi-installer.html >>>> <https://sling.apache.org/documentation/bundles/osgi-installer.html> and >>>> https://sling.apache.org/documentation/bundles/configuration-installer-factory.html >>>> >>>> Is this really the PID here? >>>> Is there some cleaning in order on the documentation or the implementation >>>> side for the OSGi Installer as well? >>> >>> The documentation is correct, configuration is based on PIDs. A >>> component either registers a ManagedService configured with a PID to get >>> the configuration with that PID or you're using a component framework >>> like Declarative Services which does the trick for you. >>> >>> So we're good on that front and in general I think we only have a few >>> places where the usage is wrong. It usually always when you want to have >>> a unique handle for a service. >>> >>>> >>>> I am wondering though, why only the PID is exposed in >>>> system/console/services/xxx and not the service id. >>> >>> The first column "Id" is the service ID :) >>> >>> Carsten >>> >>>> Konrad >>>> >>>> >>>>> On 13 Jul 2016, at 12:07, Carsten Ziegeler <[email protected]> wrote: >>>>> >>>>>> On Wed, Jul 13, 2016 at 8:01 AM, Carsten Ziegeler <[email protected]> >>>>>> wrote: >>>>>>> ...We really have to fix our code and get rid of most of the usage of >>>>>>> PIDs... >>>>>> >>>>>> And use SERVICE_ID instead when we need a unique key to the service? >>>>>> >>>>> Yes, right >>>>> >>>>> Btw, I fixed the health check core bundle, not sure which others need to >>>>> be fixed. But I guess the list is really short >>>>> >>>>> Regards >>>>> >>>>> Carsten >>>>> >>>>> -- >>>>> Carsten Ziegeler >>>>> Adobe Research Switzerland >>>>> [email protected] >>>>> >>>> >>>> >>> >>> >>> >>> >>> -- >>> Carsten Ziegeler >>> Adobe Research Switzerland >>> [email protected] >> >> > > > > > -- > Carsten Ziegeler > Adobe Research Switzerland > [email protected] <mailto:[email protected]>
