public interface HandlerMapping
This class can be implemented by application developers, although this is not
are included in the framework. The first is the default if no HandlerMapping
bean is registered in the portlet application context.
HandlerMapping implementations can support mapped interceptors but do not
have to. A handler will always be wrapped in a
instance, optionally accompanied by some
The DispatcherPortlet will first call each HandlerInterceptor's
preHandle method in the given order, finally invoking the handler
itself if all
preHandle methods have returned
The ability to parameterize this mapping is a powerful and unusual capability of this Portlet MVC framework. For example, it is possible to write a custom mapping based on session state, cookie state or many other variables. No other MVC framework seems to be equally flexible.
Note: Implementations can implement the
interface to be able to specify a sorting order and thus a priority for getting
applied by DispatcherPortlet. Non-Ordered instances get treated as lowest priority.
HandlerExecutionChain getHandler(PortletRequest request) throws java.lang.Exception
The returned HandlerExecutionChain contains a handler Object, rather than even a tag interface, so that handlers are not constrained in any way. For example, a HandlerAdapter could be written to allow another framework's handler objects to be used.
null if no match was found. This is not an error.
The DispatcherPortlet will query all registered HandlerMapping beans to find
a match, and only decide there is an error if none can find a handler.
request- current portlet request
java.lang.Exception- if there is an internal error