On 23 August 2011 10:18, 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.
Very true, and once you give a developer the a route to programatically opt for a request, rather than declaratively, they will add loads of servlets at the /* level, usually in the last minutes before a deadline. That kills all hope of performance. > > So for the use case at hand I would rather go with a special > dispatching option servlet than extending our already complicated > resolution mechanism. Although we have used Opting servlets, we have tried to avoid them. They are usually an indication that we got something wrong in the URL IA. Fixing that often removed the need. Ian > > 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] >
