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

Reply via email to