I have to look at the special dispatching option servlet. Also I should try to find documentation on what OptingServelts are meant for. To justify the framework support they must have some more use than what one could also achieve with a simple if/else in the the service method.
On Tue, Aug 23, 2011 at 11:18 AM, Carsten Ziegeler <[email protected]> wrote: > 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. The usecase seems to be actually using the tested functionality (which then conflicts with the test). Cheers, Reto > > 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] >
