Spring Framework
  1. Spring Framework
  2. SPR-5763

Make ServletHandlerMethodResolver top level type

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Duplicate
    • Affects Version/s: 3.0 M3
    • Fix Version/s: None
    • Component/s: Web
    • Last commented by a User:
      false

      Description

      AnnotationMethodHandlerAdapter contains a private class ServletHandlerMethodResolver that could be used to tweak URL mappings for custom requirements if one was able to subclass it. Furthermore it would be very cool to use in test cases as you could easily test if you mappings work for certain requests. Currently you have to use AnnotationMethodHandlerAdapter directly and thus execute the method entirely.

        Issue Links

          Activity

          Hide
          Roberto Tyley added a comment -

          I'm voting for this issue for similar reasons I voted for SPR-5087 - to recap, at my company we've currently got a lot of work coming up that will involve us creating a wide-variety of webapps that confirm to a certain set of rules around their restful urls. Annotated controllers are good for this kind of work but they actually give us somewhat more freedom than we need, and so we're introducing our own set of domain-specific annotations that let us create controller-like objects - not using @Controller, @Request, @RequestParam etc, but annotations that are expressive and leave less room for error within our own specific domain.

          In SPR-5087 I was considering creating my own HandlerAdapter to achieve this, but it might also be possible to re-use AnnotationMethodHandlerAdapter if the currently-private getMethodResolver() method could be overridden to create a HandlerMethodResolver of my own devising. For my particular use-case the HandlerMethodResolver would still need to expose the resolveHandlerMethod(HttpServletRequest) method that is added by ServletHandlerMethodResolver so that AnnotationMethodHandlerAdapter can call it, but the innards of the class would be more-or-less be completely replaced, so maybe 'ServletHandlerMethodResolver' would become an interface, and the current implementation would be pushed down into a 'RequestMappingAnnotatedHandlerMethodResolver'... or something with a shorter name.

          Show
          Roberto Tyley added a comment - I'm voting for this issue for similar reasons I voted for SPR-5087 - to recap, at my company we've currently got a lot of work coming up that will involve us creating a wide-variety of webapps that confirm to a certain set of rules around their restful urls. Annotated controllers are good for this kind of work but they actually give us somewhat more freedom than we need, and so we're introducing our own set of domain-specific annotations that let us create controller-like objects - not using @Controller, @Request, @RequestParam etc, but annotations that are expressive and leave less room for error within our own specific domain. In SPR-5087 I was considering creating my own HandlerAdapter to achieve this, but it might also be possible to re-use AnnotationMethodHandlerAdapter if the currently-private getMethodResolver() method could be overridden to create a HandlerMethodResolver of my own devising. For my particular use-case the HandlerMethodResolver would still need to expose the resolveHandlerMethod(HttpServletRequest) method that is added by ServletHandlerMethodResolver so that AnnotationMethodHandlerAdapter can call it, but the innards of the class would be more-or-less be completely replaced, so maybe 'ServletHandlerMethodResolver' would become an interface, and the current implementation would be pushed down into a 'RequestMappingAnnotatedHandlerMethodResolver'... or something with a shorter name.
          Hide
          Gary Feltham added a comment -

          I'm also voting for this improvement. We use additional annotations along with @RequestMapping. These annotations are a permission based model (not spring security but home grown) which check whether the requesting user is authorised to run the request.

          To achieve this goal, we rewrote the method AnnotationMethodHandlerAdaptor#invokeHandlerMethod(HttpServletRequest, HttpServletResponse, Object) using our own code for validation.

          ...
          ServletHandlerMethodInvoker methodInvoker = new ServletHandlerMethodInvoker(methodResolver);
          ServletWebRequest webRequest = new ServletWebRequest(request, response);
          ExtendedModelMap implicitModel = new ExtendedModelMap();
          
          -- our authorisation check code 
          
          Object result = methodInvoker.invokeHandlerMethod(handlerMethod, handler, webRequest, implicitModel);
          ModelAndView mav = methodInvoker.getModelAndView(handlerMethod, handler.getClass(), result, implicitModel,
          					webRequest);
          ...
          

          Having ServletHandlerMethodResolver made public would enable us to subclass directly before invoking the resolved method. Alternatively a protected boolean preInvoke(request, response, handlerMethod) would provide the functionality I am particularly after. (returning true to continue or false to return immediately)

          Show
          Gary Feltham added a comment - I'm also voting for this improvement. We use additional annotations along with @RequestMapping. These annotations are a permission based model (not spring security but home grown) which check whether the requesting user is authorised to run the request. To achieve this goal, we rewrote the method AnnotationMethodHandlerAdaptor#invokeHandlerMethod(HttpServletRequest, HttpServletResponse, Object) using our own code for validation. ... ServletHandlerMethodInvoker methodInvoker = new ServletHandlerMethodInvoker(methodResolver); ServletWebRequest webRequest = new ServletWebRequest(request, response); ExtendedModelMap implicitModel = new ExtendedModelMap(); -- our authorisation check code Object result = methodInvoker.invokeHandlerMethod(handlerMethod, handler, webRequest, implicitModel); ModelAndView mav = methodInvoker.getModelAndView(handlerMethod, handler.getClass(), result, implicitModel, webRequest); ... Having ServletHandlerMethodResolver made public would enable us to subclass directly before invoking the resolved method. Alternatively a protected boolean preInvoke(request, response, handlerMethod) would provide the functionality I am particularly after. (returning true to continue or false to return immediately)
          Hide
          rubal sky added a comment -

          Yes,I having the same problem.

          Show
          rubal sky added a comment - Yes,I having the same problem.
          Hide
          Oleksandr Maksymchuk added a comment -

          I support this. I'm looking for the easiest way to wrap around methodInvoker.invokeHandlerMethod(...) instead of copying the whole AnnotationMethodHandlerAdapter.

          Show
          Oleksandr Maksymchuk added a comment - I support this. I'm looking for the easiest way to wrap around methodInvoker.invokeHandlerMethod(...) instead of copying the whole AnnotationMethodHandlerAdapter.
          Hide
          Oleksandr Maksymchuk added a comment -

          SPR-7451 is better describing possible implementation we need.

          Show
          Oleksandr Maksymchuk added a comment - SPR-7451 is better describing possible implementation we need.
          Hide
          Rossen Stoyanchev added a comment -

          SPR-8214 introduces a new RequestMappingHandlerMethodAdapter that provides significantly improved customization of handler method argument processing. The code is available in trunk and is enabled by default in the MVC namespace. While the actual description of this issue is different, I believe the new HandlerAdapter is in the spirit of what has been requested. Those of you who commented with specific use cases, your feedback would be appreciated.

          Show
          Rossen Stoyanchev added a comment - SPR-8214 introduces a new RequestMappingHandlerMethodAdapter that provides significantly improved customization of handler method argument processing. The code is available in trunk and is enabled by default in the MVC namespace. While the actual description of this issue is different, I believe the new HandlerAdapter is in the spirit of what has been requested. Those of you who commented with specific use cases, your feedback would be appreciated.
          Hide
          Rossen Stoyanchev added a comment -

          I am resolving this as duplicate of SPR-5087. See the comments I left there regarding the new annotated-controller processing infrastructure. That should address the issue described above. If there is something still missing based on the new classes please open a new ticket.

          Show
          Rossen Stoyanchev added a comment - I am resolving this as duplicate of SPR-5087 . See the comments I left there regarding the new annotated-controller processing infrastructure. That should address the issue described above. If there is something still missing based on the new classes please open a new ticket.
          Hide
          Andreas Etzlstorfer added a comment -

          when is this going to be fixed?

          Show
          Andreas Etzlstorfer added a comment - when is this going to be fixed?
          Hide
          Rossen Stoyanchev added a comment -

          Note this ticket is marked 'resolved'. See my two comments above and also catch up on the new @MVC support classes.

          Show
          Rossen Stoyanchev added a comment - Note this ticket is marked 'resolved'. See my two comments above and also catch up on the new @MVC support classes .

            People

            • Assignee:
              Rossen Stoyanchev
              Reporter:
              Oliver Gierke
              Last updater:
              Trevor Marshall
            • Votes:
              7 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Days since last comment:
                2 years, 6 weeks, 5 days ago