You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Bertrand Delacretaz <bd...@apache.org> on 2022/05/11 15:14:07 UTC
Should Sling refuse to register multiple servlets with the same mount parameters?
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
Re: Should Sling refuse to register multiple servlets with the same mount parameters?
Posted by Carsten Ziegeler <cz...@apache.org>.
Thanks and no worries :)
Carsten
Am 12.05.2022 um 15:29 schrieb Konrad Windszus:
> 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 <cz...@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 <cz...@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 <bd...@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
>>>> cziegeler@apache.org
>>
>> --
>> Carsten Ziegeler
>> Adobe
>> cziegeler@apache.org
>
--
Carsten Ziegeler
Adobe
cziegeler@apache.org
Re: Should Sling refuse to register multiple servlets with the same mount parameters?
Posted by Konrad Windszus <kw...@apache.org>.
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 <cz...@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 <cz...@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 <bd...@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
>>> cziegeler@apache.org
>
> --
> Carsten Ziegeler
> Adobe
> cziegeler@apache.org
Re: Should Sling refuse to register multiple servlets with the same mount parameters?
Posted by Carsten Ziegeler <cz...@apache.org>.
? 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 <cz...@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 <bd...@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
>> cziegeler@apache.org
>
--
Carsten Ziegeler
Adobe
cziegeler@apache.org
Re: Should Sling refuse to register multiple servlets with the same mount parameters?
Posted by Konrad Windszus <ko...@gmx.de>.
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 <cz...@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 <bd...@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
> cziegeler@apache.org
Re: Should Sling refuse to register multiple servlets with the same mount parameters?
Posted by Konrad Windszus <ko...@gmx.de>.
I clarified the documentation in https://github.com/apache/sling-site/commit/cb12f47c7b55bd03ccf0951c112df68a40d67fd2 and added a link to https://docs.osgi.org/specification/osgi.core/8.0.0/framework.service.html#framework.service.servicerankingorder
The according code is IMHO in https://github.com/apache/sling-org-apache-sling-servlets-resolver/blob/1603a0ecb2ab8b4395560c0d53d9e5569b68a568/src/main/java/org/apache/sling/servlets/resolver/internal/resource/MergingServletResourceProvider.java#L107
Although additional test cases are obviously nice, I don’t think we need to change anything about the implementation.
Konrad
> On 11. May 2022, at 17:29, Bertrand Delacretaz <bd...@apache.org> wrote:
>
> Hi,
>
> Le mer. 11 mai 2022 à 17:23, Carsten Ziegeler <cz...@apache.org> a écrit :
>> ...Service ranking is more predictable than just using the "first"...
>
> I agree, but what if two servlets have the exact same service
> parameters including service ranking?
>
> That's what I think we should reject.
>
> -Bertrand
Re: Should Sling refuse to register multiple servlets with the same mount parameters?
Posted by Carsten Ziegeler <cz...@apache.org>.
The behaviour is predictable, *if* service ranking is used. Thats the
reason for this property :) Agreed, if not, then you are back to
installation order which is not predictable.
Now, if there are overlapping servlet registrations where some of them
are ignored, yes, we should log warnings.
Regards
Carsten
Am 11.05.2022 um 17:35 schrieb Bertrand Delacretaz:
> Le mer. 11 mai 2022 à 17:32, Konrad Windszus <ko...@gmx.de> a écrit :
>> ...Service IDs are always unique, so this mechanism will always establish one winner!..
>
> Yes, but that winner is not predictable from the programmer's point of
> view, that's why 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.
>
> -Bertrand
--
Carsten Ziegeler
Adobe
cziegeler@apache.org
Re: Should Sling refuse to register multiple servlets with the same mount parameters?
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le mer. 11 mai 2022 à 17:32, Konrad Windszus <ko...@gmx.de> a écrit :
> ...Service IDs are always unique, so this mechanism will always establish one winner!..
Yes, but that winner is not predictable from the programmer's point of
view, that's why 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.
-Bertrand
Re: Should Sling refuse to register multiple servlets with the same mount parameters?
Posted by Konrad Windszus <ko...@gmx.de>.
Just look at http://docs.osgi.org/javadoc/r4v43/core/org/osgi/framework/BundleContext.html#getServiceReference(java.lang.Class)
"If multiple such services exist, the service with the highest ranking (as specified in its Constants.SERVICE_RANKING property) is returned.
If there is a tie in ranking, the service with the lowest service ID (as specified in its Constants.SERVICE_ID property); that is, the service that was registered first is returned."
Service IDs are always unique, so this mechanism will always establish one winner!
Konrad
> On 11. May 2022, at 17:29, Bertrand Delacretaz <bd...@apache.org> wrote:
>
> Hi,
>
> Le mer. 11 mai 2022 à 17:23, Carsten Ziegeler <cz...@apache.org> a écrit :
>> ...Service ranking is more predictable than just using the "first"...
>
> I agree, but what if two servlets have the exact same service
> parameters including service ranking?
>
> That's what I think we should reject.
>
> -Bertrand
Re: Should Sling refuse to register multiple servlets with the same mount parameters?
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
Le mer. 11 mai 2022 à 17:23, Carsten Ziegeler <cz...@apache.org> a écrit :
> ...Service ranking is more predictable than just using the "first"...
I agree, but what if two servlets have the exact same service
parameters including service ranking?
That's what I think we should reject.
-Bertrand
Re: Should Sling refuse to register multiple servlets with the same mount parameters?
Posted by Carsten Ziegeler <cz...@apache.org>.
+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 <bd...@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
cziegeler@apache.org
Re: Should Sling refuse to register multiple servlets with the same mount parameters?
Posted by Konrad Windszus <ko...@gmx.de>.
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 <bd...@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