Central dispatcher for use within the Portlet MVC framework, e.g. for web UI
controllers. Dispatches to registered handlers for processing a portlet request.

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 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 SimpleControllerHandlerAdapter
for Spring's Controller interface.
A default 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
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
PortletMultipartResolver implementation.
An implementations for Jakarta Commons FileUpload is included:
CommonsPortletMultipartResolver.
The MultipartResolver bean name is "portletMultipartResolver"; default is none.

NOTE: The @RequestMapping annotation 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.
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.

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 ContextLoaderListener,
if any, will be shared.

DEFAULT_VIEW_RENDERER_URL

Default URL to ViewRendererServlet. This bridge servlet is used to convert
portlet render requests to servlet requests in order to leverage the view support
in the org.springframework.web.view package.

ACTION_EXCEPTION_SESSION_ATTRIBUTE

Unlike the Servlet version of this class, we have to deal with the
two-phase nature of the portlet request. To do this, we need to pass
forward any exception that occurs during the action phase, so that
it can be displayed in the render phase. The only direct way to pass
things forward and preserve them for each render request is through
render parameters, but these are limited to String objects and we need
to pass the Exception itself. The only other way to do this is in the
session. The bad thing about using the session is that we have no way
of knowing when we are done re-rendering the request and so we don't
know when we can remove the objects from the session. So we will end
up polluting the session with an old exception when we finally leave
the render phase of one request and move on to something else.

getDefaultStrategies

Create a List of default strategy objects for the given strategy interface.

The default implementation uses the "DispatcherPortlet.properties" file
(in the same package as the DispatcherPortlet class) to determine the class names.
It instantiates the strategy objects and satisifies ApplicationContextAware
if necessary.

doActionService

The handler will be obtained by applying the portlet's HandlerMappings in order.
The HandlerAdapter will be obtained by querying the portlet's installed
HandlerAdapters to find the first that supports the handler class.

doRenderService

The handler will be obtained by applying the portlet's HandlerMappings in order.
The HandlerAdapter will be obtained by querying the portlet's installed
HandlerAdapters to find the first that supports the handler class.

doResourceService

Processes the actual dispatching to the handler for resource requests.

The handler will be obtained by applying the portlet's HandlerMappings in order.
The HandlerAdapter will be obtained by querying the portlet's installed
HandlerAdapters to find the first that supports the handler class.

doEventService

The handler will be obtained by applying the portlet's HandlerMappings in order.
The HandlerAdapter will be obtained by querying the portlet's installed
HandlerAdapters to find the first that supports the handler class.