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. 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). In case I want to deploy a configuration through the OSGi installer, I want to make sure it gets bound to the right component.
Have you any reference about the format of the PID which must be used here? 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]
