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