[
https://issues.apache.org/jira/browse/SLING-2191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13193882#comment-13193882
]
Krystian Nowak commented on SLING-2191:
---------------------------------------
The problem described in this issue doesn't seem to be an edge case for me.
Please look at my example this time:
We have two (and possibly more) implementations of the OptingServlet interface.
They are configured to work on the same resourceType, the same method and no
selectors. Each of them chooses to accept a request based on a request
parameter. For us they should be able to work independently as long as the
accept logic for is mutually exclusive for both of them.
Sadly this is not the case. Only one of them is chosen to handle the request
and if the selected servlet decides to not accept it, the other servlet is
omitted. The resolver seems to choose the handling servlet based on an order
determined while registering (starting bundle) - we are using Felix here.
We could of course choose to use different resourceTypes or selectors but this
does not solve the problem, as there are multiple applications on the platform
and each one of them can potentially break another.
The solution or rather workaround to register a delegating OptingServlet, which
holds references to a set of other servlets, and invokes them in turn isn't
suitable for us, as it synchronizes too much development on multiple
Sling-based applications by separate teams (distributed also geographically,
but also organizationally).
Also workarounds for 2 servlets only doesn't work well in larger systems, as we
have already encountered need for more than 2 OptingServlets. I guess you can
imagine it being even harder when multiple development teams produce code
containing OptingServlets which should just work depending on dynamically
evaluated conditions and not globally dispatched or globally synchronized
uniqueness of selectors.
Also the usage of regexp does not fulfil all our requirements. It also shows
that the case of dynamic evaluation of conditions is not that very unusual as
you might have assumed.
Additionally, the urge to limit OptingServlet's functionality for the sake of
forcing _developers_ to use good practices of declarative configuration vs
programatical opting for request handing really limits
platforms (even the larger ones) built on Sling, so that it is just not
possible to use the platform for (yes, sometimes considered as edge-cases, but
still needed in the real-live) solutions. I wouldn't like to support here the
argument of developers facing a deadline to be valid in all cases. You cannot
just to rule not to prohibit selling kitchen knifes in order to prevent
crimes...
OptingServlets - even if considered usable rather in exceptional cases, they
have been introduced - that's the fact. So, they should also work (although it
might not be a good practice to use it often) as intuitively as they are
understood by merely reading
[http://sling.apache.org/site/servlets.html#Servlets-OptingServletinterface] or
[http://sling.apache.org/apidocs/sling5/org/apache/sling/api/servlets/OptingServlet.html].
> Allow multiple OptingServletS for the same resource type
> --------------------------------------------------------
>
> Key: SLING-2191
> URL: https://issues.apache.org/jira/browse/SLING-2191
> Project: Sling
> Issue Type: Bug
> Reporter: Reto Bachmann-Gmür
> Attachments: SLING-2191-tests-launchpad.patch
>
>
> It should be possible to have multiple OptinServlets (accepting different
> sets of requests) for the same resource type.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
