> 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]
