[
https://issues.apache.org/jira/browse/SLING-6578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15889982#comment-15889982
]
Felix Meschberger commented on SLING-6578:
------------------------------------------
TL;DR: Suggest to still use the service.pid. Define the function to use the
service.pid for references and it will be usable.
Well, yes, the service.pid for factory configurations will be automatically
generated, yet it is stable. And actually, please don't call it UUID. It just
so happens in the Apache Felix implementations. The specifications just says,
it must be unique, it could just as well be a counter.
I think we have to make sure to not mix concepts and specifications and
expectations.
"service.pid" can be assigned to any service as a static identifier.
Independent of anything else in the OSGi world of specifications and services.
Declarative Services uses the configuration pid which may be the
configuration-pid or name attribute of the component declaration to link the
Configuration Admin configuration to the component. Depending on whether the
configuration pid refers to a factory configuration PID or a singleton
configurtion PID, multiple component instances or a single component instance
may be created. So far this has nothing to do with service.pid or
service.factoryPid. At most it is component.name which is something specific to
Declarative Services.
Also note that when talking "component", I would expect people to generally
assume a Declarative Services component. This may or may not be a service (it
generally is, but there is no requirement). And it has nothing to do with how
the service is referred to. Declarative Services is just a way to deploy
services. It is not a prescriptive way of consuming services. And depending on
Declarative Services for service deployment, when you consume services, is just
plain wrong (and fragile, and so).
Next in the game is Configuration Admin Service. Configuration Admin Service
uses the service.pid property of a ManagedService or ManagedServiceFactory
service to decide what configuration to provide to the respective
ManagedService\[Factory\]. This is a specifically define use of the service.pid
property for specific services (ManagedService and ManagedServiceFactory) and
it is defined how the service.pid value is used in this context. Configuration
Admin sets a number of properties in the configuration object provided to
configuration consumers: service.pid to be configuration object identifier,
service.factoryPid to be the factory configuration (collection of similar
configurations) identifier and service.bundleLocation to identify the
configuration "owner".
The complexity that you may encounter stems from the fact, that Declarative
Services uses all the (public) properties of Configuration Admin Configuration
as service properties when registering services. This means, that in the
context of Declarative Services, the service.pid property may be derived from
the configuration supplied by the Configuration Admin service.
But the Declarative Services specification also states:
{quote}
If the component description specifies multiple configuration PIDs, then the
order of the service.pid property values from the corresponding configurations
matches the order the configuration PIDs are specified in the component
description. The values of the service.pid component property are the values as
they come from the configuration sources which, for Configuration objects, may
be more detailed than the configuration PIDs specified in the component
description.
{quote}
This means, that for a DS component, the service.pid is the combination of the
service.pid property set as a static component property plus the service.pid
from the configuration object.
> Use "service.pid" property instead of class name to reference validators
> ------------------------------------------------------------------------
>
> Key: SLING-6578
> URL: https://issues.apache.org/jira/browse/SLING-6578
> Project: Sling
> Issue Type: Improvement
> Reporter: Konrad Windszus
> Assignee: Konrad Windszus
>
> Leveraging the component's "service.pid" property value instead of its
> classname is more stable (even if implementation changes, the PID might stay
> the same) and also allows for configuration factories to refer to a specific
> validator configuration. The fallback should be the property "component.name"
> as "service.pid" is not always necessarily set. Basically the validator
> should be referable via each of those value, i.e. one of the "service.pid"s
> or the "component.name".
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
