| org.springframework.web.servlet.support.WebContentGenerator
 org.springframework.web.servlet.mvc.AbstractController
All known Subclasses: org.springframework.web.servlet.mvc.BaseCommandController, org.springframework.web.servlet.mvc.AbstractUrlViewController, org.springframework.web.servlet.mvc.ParameterizableViewController, org.springframework.web.servlet.mvc.multiaction.MultiActionController, org.springframework.web.servlet.mvc.ServletForwardingController, org.springframework.web.servlet.mvc.ServletWrappingController,
| AbstractController | | abstract public class AbstractController extends WebContentGenerator implements Controller(Code) | | Convenient superclass for controller implementations, using the Template
Method design pattern.
As stated in the
org.springframework.web.servlet.mvc.Controller Controller interface, a lot of functionality is already provided by certain abstract
base controllers. The AbstractController is one of the most important
abstract base controller providing basic features such as the generation
of caching headers and the enabling or disabling of
supported methods (GET/POST).
Workflow
(and that defined by interface):
-
AbstractController.handleRequest(HttpServletRequest,HttpServletResponse) handleRequest() will be called by the DispatcherServlet
- Inspection of supported methods (ServletException if request method
is not support)
- If session is required, try to get it (ServletException if not found)
- Set caching headers if needed according to cacheSeconds propery
- Call abstract method
AbstractController.handleRequestInternal(HttpServletRequest,HttpServletResponse) handleRequestInternal() (optionally synchronizing around the call on the HttpSession),
which should be implemented by extending classes to provide actual
functionality to return
org.springframework.web.servlet.ModelAndView ModelAndView objects.
Exposed configuration properties
(and those defined by interface):
| name
| default |
description |
| supportedMethods |
GET,POST |
comma-separated (CSV) list of methods supported by this controller,
such as GET, POST and PUT |
| requireSession |
false |
whether a session should be required for requests to be able to
be handled by this controller. This ensures that derived controller
can - without fear of null pointers - call request.getSession() to
retrieve a session. If no session can be found while processing
the request, a ServletException will be thrown |
| cacheSeconds |
-1 |
indicates the amount of seconds to include in the cache header
for the response following on this request. 0 (zero) will include
headers for no caching at all, -1 (the default) will not generate
any headers and any positive number will generate headers
that state the amount indicated as seconds to cache the content |
| synchronizeOnSession |
false |
whether the call to handleRequestInternal should be
synchronized around the HttpSession, to serialize invocations
from the same client. No effect if there is no HttpSession.
|
author:
Rod Johnson
author:
Juergen Hoeller
See Also: WebContentInterceptor |
| isSynchronizeOnSession | | final public boolean isSynchronizeOnSession()(Code) | | Return whether controller execution should be synchronized on the session.
|
| setSynchronizeOnSession | | final public void setSynchronizeOnSession(boolean synchronizeOnSession)(Code) | | Set if controller execution should be synchronized on the session,
to serialize parallel invocations from the same client.
More specifically, the execution of the handleRequestInternal
method will get synchronized if this flag is "true". The best available
session mutex will be used for the synchronization; ideally, this will
be a mutex exposed by HttpSessionMutexListener.
The session mutex is guaranteed to be the same object during
the entire lifetime of the session, available under the key defined
by the SESSION_MUTEX_ATTRIBUTE constant. It serves as a
safe reference to synchronize on for locking on the current session.
In many cases, the HttpSession reference itself is a safe mutex
as well, since it will always be the same object reference for the
same active logical session. However, this is not guaranteed across
different servlet containers; the only 100% safe way is a session mutex.
See Also: org.springframework.web.servlet.mvc.AbstractController.handleRequestInternal
See Also: org.springframework.web.util.HttpSessionMutexListener
See Also: org.springframework.web.util.WebUtils.getSessionMutex(javax.servlet.http.HttpSession) |
| Methods inherited from org.springframework.web.servlet.support.WebContentGenerator | final protected void applyCacheSeconds(HttpServletResponse response, int seconds)(Code)(Java Doc)
final protected void applyCacheSeconds(HttpServletResponse response, int seconds, boolean mustRevalidate)(Code)(Java Doc)
final protected void cacheForSeconds(HttpServletResponse response, int seconds)(Code)(Java Doc)
final protected void cacheForSeconds(HttpServletResponse response, int seconds, boolean mustRevalidate)(Code)(Java Doc)
final protected void checkAndPrepare(HttpServletRequest request, HttpServletResponse response, boolean lastModified) throws ServletException(Code)(Java Doc)
final protected void checkAndPrepare(HttpServletRequest request, HttpServletResponse response, int cacheSeconds, boolean lastModified) throws ServletException(Code)(Java Doc)
final public int getCacheSeconds()(Code)(Java Doc)
final public String[] getSupportedMethods()(Code)(Java Doc)
final public boolean isRequireSession()(Code)(Java Doc)
final public boolean isUseCacheControlHeader()(Code)(Java Doc)
final public boolean isUseExpiresHeader()(Code)(Java Doc)
final protected void preventCaching(HttpServletResponse response)(Code)(Java Doc)
final public void setCacheSeconds(int seconds)(Code)(Java Doc)
final public void setRequireSession(boolean requireSession)(Code)(Java Doc)
final public void setSupportedMethods(String[] methods)(Code)(Java Doc)
final public void setUseCacheControlHeader(boolean useCacheControlHeader)(Code)(Java Doc)
final public void setUseExpiresHeader(boolean useExpiresHeader)(Code)(Java Doc)
|
|
|