Re: Should Sling refuse to register multiple servlets with the same mount parameters?

2022-05-12 Thread Carsten Ziegeler

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  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  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
 

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  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




--
Carsten Ziegeler
Adobe
cziege...@apache.org


Re: Should Sling refuse to register multiple servlets with the same mount parameters?

2022-05-12 Thread 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  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  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
  
 
 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  
> 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



Re: Should Sling refuse to register multiple servlets with the same mount parameters?

2022-05-11 Thread Konrad Windszus
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  wrote:
> 
> Hi,
> 
> Le mer. 11 mai 2022 à 17:23, Carsten Ziegeler  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?

2022-05-11 Thread Carsten Ziegeler
? 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  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
 

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  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


Re: Should Sling refuse to register multiple servlets with the same mount parameters?

2022-05-11 Thread Carsten Ziegeler
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  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
cziege...@apache.org


Re: Should Sling refuse to register multiple servlets with the same mount parameters?

2022-05-11 Thread 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  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
>>  
>> 
>> 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  
>>> 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



Re: Should Sling refuse to register multiple servlets with the same mount parameters?

2022-05-11 Thread Bertrand Delacretaz
Le mer. 11 mai 2022 à 17:32, Konrad Windszus  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?

2022-05-11 Thread Konrad Windszus
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  wrote:
> 
> Hi,
> 
> Le mer. 11 mai 2022 à 17:23, Carsten Ziegeler  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?

2022-05-11 Thread Bertrand Delacretaz
Hi,

Le mer. 11 mai 2022 à 17:23, Carsten Ziegeler  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?

2022-05-11 Thread Carsten Ziegeler

+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
 


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  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


Re: Should Sling refuse to register multiple servlets with the same mount parameters?

2022-05-11 Thread 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
 


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  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