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

HandlerInterceptor improvement - insufficient context (no handler method) information [SPR-7408] #12066

Closed
spring-projects-issues opened this issue Jul 30, 2010 · 5 comments
Assignees
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) type: enhancement A general enhancement
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

sandstorm opened SPR-7408 and commented

When implementing @Controllers, one may have multiple handling methods, as opposed to the old fashion Controller-interface style-based ones.

The problem is that when implementing HandlerInterceptors one may not infer the handling method being invoked. For example if one wants to check if the current handling method being invoked has been annotated, thats impossible, and is 'of importance'.

Consider this method signature:

public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {

Currently the handler parameter represents the controller class and not any particular handling method.
The actual proposal is this Object to be of class java.lang.Method if the class implementing that is annotated with @Controller, instead of implementing the Controller interface, otherwise it may retain the current semantics for compatibility reasons.

It is expected that in the case being discussed the Object handler parameter currently provides no benefit, and is of no use to anybody implementing a @Controller, therefore it is expected not to introduce any backwards compatibility issues thereof.

Several workarounds have been researched but this solution remains of particular neatness and simplicity.

The solution implementation is estimated to be simple, and cheap in terms of time, so please, Spring fellows, do something.

Thank you.


2 votes, 5 watchers

@spring-projects-issues
Copy link
Collaborator Author

sandstorm commented

My bad: java.lang.reflect.Method is meant.

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Apr 26, 2011

Rossen Stoyanchev commented

The introduction of HandlerMethod-based implementations of HandlerMapping and HandlerAdapter (#13060), this issue is also addressed. The object in the preHandle and postHandle mehtods is a HandlerMethod.

@spring-projects-issues
Copy link
Collaborator Author

Lei Zhou commented

Could we also adapte the improvement to the portlet realm? Looking at the V3.1/3.1.1 release notes, I really feel that the 'portlet guys' are left out :)

@spring-projects-issues
Copy link
Collaborator Author

Chris Beams commented

Lei, if this is still important to you, please open a new issue against the Web:Portlet component and mention this issue ID, thanks.

@spring-projects-issues
Copy link
Collaborator Author

Nishant S commented

Under what configuration is the object in HandlerInterceptor an instance of the HandlerMethod class? My setup is without mvc:annotation-driven/. I have a controller class marked @Controller and handler methods with @RequestMapping(...) annotations. I see the controller class as the object in the interceptor

@spring-projects-issues spring-projects-issues added type: enhancement A general enhancement in: web Issues in web modules (web, webmvc, webflux, websocket) labels Jan 11, 2019
@spring-projects-issues spring-projects-issues added this to the 3.1 M2 milestone Jan 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

2 participants