The easiest way to expose an HttpRequestHandler bean in Spring style
is to define it in Spring's root web application context and define
in web.xml, pointing at the target HttpRequestHandler bean
through its servlet-name which needs to match the target bean name.
Supported as a handler type within Spring's
DispatcherServlet , being able
to interact with the dispatcher's advanced mapping and interception
facilities. This is the recommended way of exposing an HttpRequestHandler,
while keeping the handler implementations free of direct dependencies
on a DispatcherServlet environment.
Typically implemented to generate binary responses directly,
with no separate view resource involved. This differentiates it from a
Controller within Spring's Web MVC
framework. The lack of a ModelAndView
return value gives a clearer signature to callers other than the
DispatcherServlet, indicating that there will never be a view to render.
As of Spring 2.0, Spring's HTTP-based remote exporters, such as
and HessianServiceExporter ,
implement this interface rather than the more extensive Controller interface,
for minimal dependencies on Spring-specific web infrastructure.
Note that HttpRequestHandlers may optionally implement the
just like Controllers can, provided that they run within Spring's
DispatcherServlet. However, this is usually not necessary, since
HttpRequestHandlers typically only support POST requests to begin with.
Alternatively, a handler may implement the "If-Modified-Since" HTTP
header processing manually within its handle method.