[
https://issues.apache.org/jira/browse/SLING-6578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15889864#comment-15889864
]
Konrad Windszus edited comment on SLING-6578 at 3/1/17 9:48 AM:
----------------------------------------------------------------
Ok, but currently there is no way to influence the PID of factory
configurations. Therefore referring to a PID which always contains a UUID
generated by the configuration admin will be hard, because the UUID part will
only be generated once the configuration is created (this will change though
with R7,
https://github.com/osgi/design/blob/master/rfcs/rfc0227/rfc-0227-ConfigAdminUpdates.pdf).
Therefore I think it is useful to make the validator addressable by the values
of any of the following component service properties:
# {{service.pid}}, probably mostly useful for components implicitly created
through the ConfigAdmin, and will be very useful once the alias handling is
added to the ConfigAdmin. In addition could be useful if the Validator service
is registered manually and the service.pid is explicitly set.
# {{service.factoryPid}}, probably mostly useful for DS components requiring a
factory configuration, although in this case this might resolve to any of the
Validators which are configured
# {{component.name}}, useful for DS component not requiring a configuration,
because this property is always set there.
That should lead to the fact that most validators just work without requiring
an additional property to be set.
was (Author: kwin):
Ok, but currently there is no way to influence the PID of factory
configurations. Therefore referring to a PID which always contains a UUID
generated by the configuration admin will be tough, because the UUID part will
only be generated once the configuration is created (this will change though
with R7,
https://github.com/osgi/design/blob/master/rfcs/rfc0227/rfc-0227-ConfigAdminUpdates.pdf).
Therefore I think it is useful to make the validator addressable by the values
of any of the following component service properties:
# {{service.pid}}, probably mostly useful for components implicitly created
through the ConfigAdmin, and will be very useful once the alias handling is
added to the ConfigAdmin. In addition could be useful if the Validator service
is registered manually and the service.pid is explicitly set.
# {{service.factoryPid}}, probably mostly useful for DS components requiring a
factory configuration, although in this case this might resolve to any of the
Validators which are configured
# {{component.name}}, useful for DS component not requiring a configuration,
because this property is always set there.
That should lead to the fact that most validators just work without requiring
an additional property to be set.
> 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)
