Make ServletHandlerMethodResolver top level type [SPR-5763]

[spring-projects-issues]

Oliver Drotbohm opened SPR-5763 and commented

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.

---

Affects: 3.0 M3

Issue Links:

• Make ServletHandlerMethodResolver protected (instead of private) to allow subclassing [SPR-7451] #12109 Make ServletHandlerMethodResolver protected (instead of private) to allow subclassing

7 votes, 6 watchers

[spring-projects-issues]

Roberto Tyley commented

I'm voting for this issue for similar reasons I voted for #9760 - 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 #9760 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.

[spring-projects-issues]

Gary Feltham commented

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)

[spring-projects-issues]

rubal sky commented

Yes,I having the same problem.

[spring-projects-issues]

Oleksandr Maksymchuk commented

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

[spring-projects-issues]

Oleksandr Maksymchuk commented

#12109 is better describing possible implementation we need.

[spring-projects-issues]

Rossen Stoyanchev commented

#12864 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.

[spring-projects-issues]

Rossen Stoyanchev commented

I am resolving this as duplicate of #9760. 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.

[spring-projects-issues]

Andreas Etzlstorfer commented

when is this going to be fixed?

[spring-projects-issues]

Rossen Stoyanchev commented

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