|
Generated by JDiff |
||||||||
PREV PACKAGE NEXT PACKAGE FRAMES NO FRAMES |
This file contains all the changes in documentation in the packageorg.springframework.web.portlet
as colored differences. Deletions are shownlike this, and additions are shown like this.
If no deletions or additions are shown in an entry, the HTML tags will be what has changed. The new HTML tags are shown in the differences. If no documentation existed, and then some was added in a later version, this change is noted in the appropriate class pages of differences, but the change is not shown on this page. Only changes in existing text are shown here. Similarly, documentation which was inherited from another class or interface is not shown here.
Note that an HTML error in the new documentation may cause the display of other documentation changes to be presented incorrectly. For instance, failure to close a <code> tag will cause all subsequent paragraphs to be displayed differently.
Central dispatcher for use within the Portlet MVC framework, e.g. for web UI controllers. Dispatches to registered handlers for processing a portlet request.Class DispatcherPortlet, HandlerExecutionChain getHandler(PortletRequest)This portlet is very flexible: It can be used with just about any workflow, with the installation of the appropriate adapter classes. It offers the following functionality that distinguishes it from other request-driven portlet MVC frameworks:
- It is based around a JavaBeans configuration mechanism.
- It can use any HandlerMapping implementation - pre-built or provided as part of an application - to control the routing of requests to handler objects. Default is a org.springframework.web.portlet.mvc.annotation.DefaultAnnotationHandlerMapping. HandlerMapping objects can be defined as beans in the portlet's application context, implementing the HandlerMapping interface, overriding the default HandlerMapping if present. HandlerMappings can be given any bean name (they are tested by type).
- It can use any HandlerAdapter; this allows for using any handler interface. The default adapter is org.springframework.web.portlet.mvc.SimpleControllerHandlerAdapter for Spring's org.springframework.web.portlet.mvc.Controller interface. A default org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter will be registered as well. HandlerAdapter objects can be added as beans in the application context, overriding the default HandlerAdapter. Like HandlerMappings, HandlerAdapters can be given any bean name (they are tested by type).
- The dispatcher's exception resolution strategy can be specified via a HandlerExceptionResolver, for example mapping certain exceptions to error pages. Default is none. Additional HandlerExceptionResolvers can be added through the application context. HandlerExceptionResolver can be given any bean name (they are tested by type).
- Its view resolution strategy can be specified via a ViewResolver implementation, resolving symbolic view names into View objects. Default is org.springframework.web.servlet.view.InternalResourceViewResolver. ViewResolver objects can be added as beans in the application context, overriding the default ViewResolver. ViewResolvers can be given any bean name (they are tested by type).
- The dispatcher's strategy for resolving multipart requests is determined by a org.springframework.web.portlet.multipart.PortletMultipartResolver implementation. An implementations for Jakarta Commons FileUpload is included: org.springframework.web.portlet.multipart.CommonsPortletMultipartResolver. The MultipartResolver bean name is "portletMultipartResolver"; default is none.
NOTE: The
@RequestMapping
annotation will only be processed if a correspondingHandlerMapping
(for type level annotations) and/orHandlerAdapter
(for method level annotations) is present in the dispatcher. This is the case by default. However, if you are defining customHandlerMappings
orHandlerAdapters
, then you need to make sure that a corresponding customDefaultAnnotationHandlerMapping
and/orAnnotationMethodHandlerAdapter
is defined as well - provided that you intend to use@RequestMapping
.A web application can define any number of DispatcherPortlets. Each portlet will operate in its own namespace, loading its own application context with mappings, handlers, etc. Only the root application context as loaded by org.springframework.web.context.ContextLoaderListener, if any, will be shared.
Thanks to Rainer Schmitz
and, Nick Lothian and Eric Dalquist for their suggestions! @author William G. Thompson, Jr. @author John A. Lewis @author Juergen Hoeller @since 2.0 @see org.springframework.web.portlet.mvc.Controller @see org.springframework.web.servlet.ViewRendererServlet @see org.springframework.web.context.ContextLoaderListener
Return the HandlerExecutionChain for this request. Try all handler mappings in order. @param request current portlet request @param cache whether to cache the HandlerExecutionChain in a request attribute @return theHandlerExceutionChainHandlerExecutionChain, or null if no handler could be found
{@inheritDoc}Any@throwsenvironment set here overrides theIllegalArgumentException if environment is notStandardPortletEnvironmentassignableprovidedtoby{@codedefaultConfigurableEnvironment}.