I'm not sure if we really should change this :) OptingServlet should be an exception and not the default case of handling requests. Remember for example that as soon as you're using an opting servlet, the resolution can't be cached.
So for the use case at hand I would rather go with a special dispatching option servlet than extending our already complicated resolution mechanism. Regards Carsten 2011/8/22 Ian Boston <[email protected]>: > On 22 August 2011 17:35, Bertrand Delacretaz <[email protected]> wrote: >> On Mon, Aug 22, 2011 at 6:03 PM, Ian Boston <[email protected]> wrote: >>> 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... >> >> Yes, IIUC that's where using a ServletResourceProvider per set of >> resource paths (as opposed to one per servlet currently) would help - >> that provider would then be mapped to the set of servlets that share >> the same set of resource paths, and select the one that accepts the >> current request. > > Your memory is better than mine both in terms of retrieval and correctness. :) > >> >>> ...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 ?... >> >> I'd use the first one that accepts the request, and keep the servlets >> ordered by service ranking to make sure things are predictable. > > Yes, makes sense to me, and would work for the use cases we had. > I think in the end when we hit the problem we made compromises using > selectors rather than change how things opted... but it looks like you > and others have the same use case. > Ian > > >> >> -Bertrand >> > -- Carsten Ziegeler [email protected]
