Sorry for the confusion, my reply was referring to Bertrands mail (https://lists.apache.org/thread/45pm1vdokrdgdcdghxrfosfv516xs7f9)
"I'd like us to reject cases where it's the Service ID that defines behavior, or at least log a warning if they happen.” Konrad > On 11. May 2022, at 19:10, Carsten Ziegeler <cziege...@apache.org> wrote: > > ? not sure what you mean. I agreed to use service ranking, and service > ranking is the whole mechanism including what happens if that property is not > specified. ServiceReference has a compareTo method that does all of that. > > Carsten > > Am 11.05.2022 um 17:37 schrieb Konrad Windszus: >> Why doing it differently than for any other OSGi service? >> Although the service ID is not predictable in general older services beat >> newer services, which is IMHO good enough. >> I am fine with issuing a warn (if easy to implement) but I am against >> rejecting for consistency reasons. >> Konrad >>> On 11. May 2022, at 17:22, Carsten Ziegeler <cziege...@apache.org> wrote: >>> >>> +1 to what Konrad said. >>> >>> Service ranking is more predictable than just using the "first" >>> >>> Regards >>> Carsten >>> >>> Am 11.05.2022 um 17:18 schrieb Konrad Windszus: >>>> IMHO the regular OSGi semantics should apply here as well, i.e. higher >>>> service ranking wins (if tie lower bundle id wins). That is also >>>> documented at >>>> https://sling.apache.org/documentation/the-sling-engine/servlets.html#servlet-resolution-order >>>> >>>> <https://sling.apache.org/documentation/the-sling-engine/servlets.html#servlet-resolution-order> >>>> In any case this should only be the last criteria if selectors, extensions >>>> and method are the same for more then one servlet resolution candidate. >>>> Throwing an exception/refusing to register the servlet is wrong and would >>>> be a regression. >>>> Konrad >>>>> On 11. May 2022, at 17:14, Bertrand Delacretaz <bdelacre...@apache.org> >>>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> I forgot if we discussed this already, if that's the case pointers are >>>>> welcome. >>>>> >>>>> Adrian Kozma created SLING-11315 about this, and I tentatively added a >>>>> new test [1] to explore the current behavior. >>>>> >>>>> It looks like the first registered servlet wins, but that might be >>>>> just by chance. >>>>> >>>>> Do people agree that Sling should refuse to register servlets that >>>>> have the same set of mount parameters as existing ones? >>>>> >>>>> I think that would help avoid difficult to troubleshoot situations. >>>>> >>>>> -Bertrand >>>>> >>>>> [1] >>>>> https://github.com/apache/sling-org-apache-sling-servlets-resolver/commit/1603a0ecb2ab8b4395560c0d53d9e5569b68a568 >>> >>> -- >>> Carsten Ziegeler >>> Adobe >>> cziege...@apache.org > > -- > Carsten Ziegeler > Adobe > cziege...@apache.org