IIRC, the problem is the way in which the list of potential servlets is built and the way in which that list is processed. I think the list is built with 1 slot per pattern, and then only the first opting servlet that claims it can handle the request gets through as a ServletResource.
You can get round this by registering some Servlets under /lib and some under other locations /apps etc, then the path to each ServletResource appears differently and gets tested, however, its still the first OptingServlet that gets used, and then fundamentally, what would the code do if 2 servlets both opted to handle the same request ? Ian On 22 August 2011 16:19, Justin Edelson <[email protected]> wrote: > +1 for implementing support for multiple OptingServlets per > resourceType/methods/etc combination > > On Mon, Aug 22, 2011 at 9:10 AM, Bertrand Delacretaz > <[email protected]> wrote: >> Hi, >> >> I've been looking at SLING-2191 - it looks like if several >> OptingServlets have the exact same registration parameters, only one >> is actually used. >> >> In Reto's example there we have two servlets registered with >> >> @Property(name="sling.servlet.resourceTypes", value={ >> "sling/servlet/default", >> "sling/nonexisting" >> }), >> @Property(name="sling.servlet.methods", value={"POST","GET"}) >> >> which differ only in the results of their OptingServlet.accepts method. >> >> This causes their ServletResourceProviders to have the same provider >> roots, am I correct to assume that this is what causes one of the >> servlets to mask the other? >> >> If I'm correct, we might need to use a single ServletResourceProvider >> in such a case, and allow it to point to a set of OptingServlet. >> >> -Bertrand >> >
