Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make ServletHandlerMethodResolver top level type [SPR-5763] #10433

Closed
spring-projects-issues opened this issue May 15, 2009 · 9 comments
Closed

Make ServletHandlerMethodResolver top level type [SPR-5763] #10433

spring-projects-issues opened this issue May 15, 2009 · 9 comments

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented May 15, 2009

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:

  • #12109 Make ServletHandlerMethodResolver protected (instead of private) to allow subclassing

7 votes, 6 watchers

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jul 21, 2009

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jul 19, 2010

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jan 17, 2011

rubal sky commented

Yes,I having the same problem.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jan 26, 2011

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jan 26, 2011

Oleksandr Maksymchuk commented

#12109 is better describing possible implementation we need.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Apr 12, 2011

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jun 3, 2011

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Mar 5, 2012

Andreas Etzlstorfer commented

when is this going to be fixed?

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Mar 5, 2012

Rossen Stoyanchev commented

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants