[
https://issues.apache.org/jira/browse/SLING-6578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15890122#comment-15890122
]
Konrad Windszus edited comment on SLING-6578 at 3/1/17 1:08 PM:
----------------------------------------------------------------
bq. Can you please elaborate a little bit on this?
Sure, I was indeed thinking about factory configurations where the
{{service.pid}} is impossible to predict. But once the configuration has been
generated, the bound service will always get the same {{service.pid}} at least.
bq. Each component can have a different configuration including that special
property.
Yes, indeed. That would even apply to factory configurations where you would
make that property configurable as well
I was initially hoping for an automatically generated, stable ID I could just
reuse, instead of forcing every {{Validator}} developer to not forget about
adding a specific property. Since this doesn't seem to be the case, I think it
is indeed best to just make each validator addressable through exactly one
dedicated property value which is set in the ValidatorImpl.
Now coming to the point of overloading, if multiple validators register for the
same "address" (be it based on "service.pid" or some other property), that
would be already logged
(https://github.com/apache/sling/blob/trunk/bundles/extensions/validation/core/src/main/java/org/apache/sling/validation/impl/ValidationModelRetrieverImpl.java#L170).
Probably it would be good to take the "service.ranking" into consideration for
those cases, to make sure the highest service ranking get actually bound.
was (Author: kwin):
bq. Can you please elaborate a little bit on this?
Sure, I was indeed thinking about factory configurations where the
{{service.pid}} is impossible to predict. But once the configuration has been
generated, the bound service will always get the same {{service.pid}}.
bq. Each component can have a different configuration including that special
property.
Yes, indeed. That would even apply to factory configurations where you would
make that property configurable as well
I was initially hoping for an automatically generated, stable ID I could just
reuse, instead of forcing every {{Validator}} developer to not forget about
adding a specific property. Since this doesn't seem to be the case, I think it
is indeed best to just make each validator addressable through exactly one
dedicated property value which is set in the ValidatorImpl.
Now coming to the point of overloading, if multiple validators register for the
same "address" (be it based on "service.pid" or some other property), that
would be already logged
(https://github.com/apache/sling/blob/trunk/bundles/extensions/validation/core/src/main/java/org/apache/sling/validation/impl/ValidationModelRetrieverImpl.java#L170).
Probably it would be good to take the "service.ranking" into consideration for
those cases, to make sure the highest service ranking get actually bound.
> 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)
