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 <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
--
Carsten Ziegeler
Adobe
cziege...@apache.org
