| 
 | ||||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
| SUMMARY: REQUIRED | OPTIONAL | DETAIL: ELEMENT | |||||||||
@Target(value={METHOD,TYPE})
@Retention(value=RUNTIME)
@Documented
public @interface RequestMappingAnnotation for mapping web requests onto specific handler classes and/or handler methods. Provides consistent style between Servlet and Portlet environments, with the semantics adapting to the concrete environment.
NOTE: Method-level mappings are only allowed to narrow the mapping expressed at the class level (if any). HTTP paths / portlet modes need to uniquely map onto specific handler beans, with any given path / mode only allowed to be mapped onto one specific handler bean (not spread across multiple handler beans). It is strongly recommended to co-locate related handler methods into the same bean.
Handler methods which are annotated with this annotation are allowed to have very flexible signatures. They may have arguments of the following types, in arbitrary order (except for validation results, which need to follow right after the corresponding command object, if desired):
ServletRequest / HttpServletRequest
 or PortletRequest / ActionRequest /
 RenderRequest. Note that in the Portlet case,
 an explicitly declared action/render argument is also used for mapping
 specific request types onto a handler method (in case of no other
 information given that differentiates between action and render requests).
 HttpSession or PortletSession.
 An argument of this type will enforce the presence of a corresponding session.
 As a consequence, such an argument will never be null.
 Note that session access may not be thread-safe, in particular in a
 Servlet environment: Consider switching the
 "synchronizeOnSession"
 flag to "true" if multiple requests are allowed to access a session concurrently.
 WebRequest or
 NativeWebRequest.
 Allows for generic request parameter access as well as request/session
 attribute access, without ties to the native Servlet/Portlet API.
 Locale for the current request locale
 (determined by the most specific locale resolver available,
 i.e. the configured LocaleResolver
 in a Servlet environment and the portal locale in a Portlet environment).
 InputStream / Reader for access
 to the request's content. This will be the raw InputStream/Reader as
 exposed by the Servlet/Portlet API.
 OutputStream / Writer for generating
 the response's content. This will be the raw OutputStream/Writer as
 exposed by the Servlet/Portlet API.
 @RequestParam annotated parameters for access to
 specific Servlet/Portlet request parameters. Parameter values will be
 converted to the declared method argument type.
 Map / Model /
 ModelMap for enriching the implicit model
 that will be exposed to the web view.
 InitBinder methods
 and/or the HandlerAdapter configuration - see the "webBindingInitializer"
 property on AnnotationMethodHandlerAdapter.
 Such command objects along with their validation results will be exposed
 as model attributes, by default using the non-qualified command class name
 in property notation (e.g. "orderAddress" for type "mypackage.OrderAddress").
 Specify a parameter-level ModelAttribute annotation for declaring
 a specific model attribute name.
 Errors /
 BindingResult validation results
 for a preceding command/form object (the immediate preceding argument).
 SessionStatus status handle
 for marking form processing as complete (triggering the cleanup of session
 attributes that have been indicated by the SessionAttributes annotation
 at the handler type level).
 The following return types are supported for handler methods:
ModelAndView object (Servlet MVC or Portlet MVC),
 with the model implicitly enriched with command objects and the results
 of ModelAttribute annotated reference data accessor methods.
 Model object, with the view name
 implicitly determined through a RequestToViewNameTranslator
 and the model implicitly enriched with command objects and the results
 of ModelAttribute annotated reference data accessor methods.
 Map object for exposing a model,
 with the view name implicitly determined through a
 RequestToViewNameTranslator
 and the model implicitly enriched with command objects and the results
 of ModelAttribute annotated reference data accessor methods.
 View object, with the
 model implicitly determined through command objects and
 ModelAttribute annotated reference data accessor methods.
 The handler method may also programmatically enrich the model by
 declaring a Model argument (see above).
 String value which is interpreted as view name,
 with the model implicitly determined through command objects and
 ModelAttribute annotated reference data accessor methods.
 The handler method may also programmatically enrich the model by
 declaring a ModelMap argument
 (see above).
 void if the method handles the response itself (by
 writing the response content directly, declaring an argument of type
 ServletResponse / HttpServletResponse
 / RenderResponse for that purpose)
 or if the view name is supposed to be implicitly determined through a
 RequestToViewNameTranslator
 (not declaring a response argument in the handler method signature;
 only applicable in a Servlet environment).
 ModelAttribute at the method level (or the default attribute name
 based on the return type's class name otherwise). The model will be
 implicitly enriched with command objects and the results of
 ModelAttribute annotated reference data accessor methods.
 NOTE: @RequestMapping will only be processed if a
 corresponding HandlerMapping (for type level annotations)
 and/or HandlerAdapter (for method level annotations) is
 present in the dispatcher. This is the case by default in both
 DispatcherServlet and DispatcherPortlet.
 However, if you are defining custom HandlerMappings or
 HandlerAdapters, then you need to make sure that a
 corresponding custom DefaultAnnotationHandlerMapping
 and/or AnnotationMethodHandlerAdapter is defined as well
 - provided that you intend to use @RequestMapping.
RequestParam, 
ModelAttribute, 
SessionAttributes, 
InitBinder, 
WebRequest, 
DefaultAnnotationHandlerMapping, 
AnnotationMethodHandlerAdapter, 
DefaultAnnotationHandlerMapping, 
AnnotationMethodHandlerAdapter| Optional Element Summary | |
|---|---|
|  RequestMethod[] | methodThe HTTP request methods to map to, narrowing the primary mapping: GET, POST, HEAD, OPTIONS, PUT, DELETE, TRACE. | 
|  String[] | paramsThe parameters of the mapped request, narrowing the primary mapping. | 
|  String[] | valueThe primary mapping expressed by this annotation. | 
public abstract String[] value
In a Servlet environment: the path mapping URIs (e.g. "/myPath.do"). Ant-style path patterns are also supported (e.g. "/myPath/*.do"). At the method level, relative paths (e.g. "edit.do") are supported within the primary mapping expressed at the type level.
In a Portlet environment: the mapped portlet modes (i.e. "EDIT", "VIEW", "HELP" or any custom modes).
Supported at the type level as well as at the method level! When used at the type level, all method-level mappings inherit this primary mapping, narrowing it for a specific handler method.
In case of Servlet-based handler methods, the method names are
 taken into account for narrowing if no path was specified explicitly,
 according to the specified
 MethodNameResolver
 (by default an
 InternalPathMethodNameResolver).
 Note that this only applies in case of ambiguous annotation mappings
 that do not specify a path mapping explicitly. In other words,
 the method name is only used for narrowing among a set of matching
 methods; it does not constitute a primary path mapping itself.
 
If you have a single default method (without explicit path mapping), then all requests without a more specific mapped method found will be dispatched to it. If you have multiple such default methods, then the method name will be taken into account for choosing between them.
public abstract RequestMethod[] method
Supported at the type level as well as at the method level! When used at the type level, all method-level mappings inherit this HTTP method restriction (i.e. the type-level restriction gets checked before the handler method is even resolved).
Currently only supported in Servlet environments! To be supported for Portlet 2.0 resource requests in Spring 3.0 as well.
public abstract String[] params
Same format for any environment: a sequence of "myParam=myValue" style expressions, with a request only mapped if each such parameter is found to have the given value. "myParam" style expressions are also supported, with such parameters having to be present in the request (allowed to have any value). Finally, "!myParam" style expressions indicate that the specified parameter is not supposed to be present in the request.
Supported at the type level as well as at the method level! When used at the type level, all method-level mappings inherit this parameter restriction (i.e. the type-level restriction gets checked before the handler method is even resolved).
In a Servlet environment, parameter mappings are considered as restrictions that are enforced at the type level. The primary path mapping (i.e. the specified URI value) still has to uniquely identify the target handler, with parameter mappings simply expressing preconditions for invoking the handler.
In a Portlet environment, parameters are taken into account as mapping differentiators, i.e. the primary portlet mode mapping plus the parameter conditions uniquely identify the target handler. Different handlers may be mapped onto the same portlet mode, as long as their parameter mappings differ.
| 
 | ||||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
| SUMMARY: REQUIRED | OPTIONAL | DETAIL: ELEMENT | |||||||||