Sync with 3.1.x
* 3.1.x: (61 commits) Compensate for changes in JDK 7 Introspector Avoid 'type mismatch' errors in ExtendedBeanInfo Polish ExtendedBeanInfo and tests Infer AnnotationAttributes method return types Minor fix in MVC reference doc chapter Hibernate 4.1 etc TypeDescriptor equals implementation accepts annotations in any order "setBasenames" uses varargs now (for programmatic setup; SPR-9106) @ActiveProfiles mechanism works with @ImportResource as well (SPR-8992 polishing clarified Resource's "getFilename" method to consistently return null substituteNamedParameters detects and unwraps SqlParameterValue object Replace spaces with tabs Consider security in ClassUtils#getMostSpecificMethod Adding null check for username being null. Improvements for registering custom SQL exception translators in app c SPR-7680 Adding QueryTimeoutException to the DataAccessException hiera Minor polish in WebMvcConfigurationSupport Detect overridden boolean getters in ExtendedBeanInfo Polish ExtendedBeanInfoTests ...
This commit is contained in:
@@ -1438,7 +1438,7 @@ package fiona.apple;
|
||||
|
||||
<lineannotation>// Spring-API imports</lineannotation>
|
||||
import org.springframework.beans.BeansException;
|
||||
import org.springframework.context.Applicationcontext;
|
||||
import org.springframework.context.ApplicationContext;
|
||||
import org.springframework.context.ApplicationContextAware;
|
||||
|
||||
public class CommandManager implements ApplicationContextAware {
|
||||
|
||||
@@ -94,7 +94,7 @@
|
||||
</interfacename> registration is through <interfacename>ApplicationContext
|
||||
</interfacename> auto-detection (as described above), it is also
|
||||
possible to register them <emphasis>programmatically</emphasis>
|
||||
against an <interfacename>ApplicationContext</interfacename> using the
|
||||
against a <interfacename>ConfigurableBeanFactory</interfacename> using the
|
||||
<methodname>addBeanPostProcessor</methodname> method. This can be useful
|
||||
when needing to evaluate conditional logic before registration, or even
|
||||
for copying bean post processors across contexts in a hierarchy. Note
|
||||
|
||||
@@ -859,6 +859,69 @@ public class ClinicController {
|
||||
mechanisms see <xref linkend="aop-proxying" />.</para>
|
||||
</tip>
|
||||
|
||||
<section id="mvc-ann-requestmapping-31-vs-30">
|
||||
<title>New Support Classes for <classname>@RequestMapping</classname> methods in Spring MVC 3.1</title>
|
||||
|
||||
<para>Spring 3.1 introduced a new set of support classes for
|
||||
<classname>@RequestMapping</classname> methods called
|
||||
<classname>RequestMappingHandlerMapping</classname> and
|
||||
<classname>RequestMappingHandlerAdapter</classname> respectively.
|
||||
They are recommended for use and even required to take advantage of
|
||||
new features in Spring MVC 3.1 and going forward. The new support
|
||||
classes are enabled by default by the MVC namespace and MVC Java
|
||||
config (<classname>@EnableWebMvc</classname>) but must be configured
|
||||
explicitly if using neither. This section describes a few
|
||||
important differences between the old and the new support classes.
|
||||
</para>
|
||||
|
||||
<para>Prior to Spring 3.1, type and method-level request mappings were
|
||||
examined in two separate stages -- a controller was selected first
|
||||
by the <classname>DefaultAnnotationHandlerMapping</classname> and the
|
||||
actual method to invoke was narrowed down second by
|
||||
the <classname>AnnotationMethodHandlerAdapter</classname>.</para>
|
||||
|
||||
<para>With the new support classes in Spring 3.1, the
|
||||
<classname>RequestMappingHandlerMapping</classname> is the only place
|
||||
where a decision is made about which method should process the request.
|
||||
Think of controller methods as a collection of unique endpoints
|
||||
with mappings for each method derived from type and method-level
|
||||
<classname>@RequestMapping</classname> information.</para>
|
||||
|
||||
<para>This enables some new possibilities. For once a
|
||||
<classname>HandlerInterceptor</classname> or a
|
||||
<classname>HandlerExceptionResolver</classname> can now expect the
|
||||
Object-based handler to be a <classname>HandlerMethod</classname>,
|
||||
which allows them to examine the exact method, its parameters and
|
||||
associated annotations. The processing for a URL no longer needs to
|
||||
be split across different controllers.
|
||||
</para>
|
||||
|
||||
<para>There are also several things no longer possible:</para>
|
||||
<itemizedlist>
|
||||
<listitem><para>Select a controller first with a
|
||||
<classname>SimpleUrlHandlerMapping</classname> or
|
||||
<classname>BeanNameUrlHandlerMapping</classname> and then narrow
|
||||
the method based on <classname>@RequestMapping</classname>
|
||||
annotations.</para></listitem>
|
||||
<listitem><para>Rely on method names as a fall-back mechanism to
|
||||
disambiguate between two <classname>@RequestMapping</classname> methods
|
||||
that don't have an explicit path mapping URL path but otherwise
|
||||
match equally, e.g. by HTTP method. In the new support classes
|
||||
<classname>@RequestMapping</classname> methods have to be mapped
|
||||
uniquely.</para></listitem>
|
||||
<listitem><para>Have a single default method (without an explicit
|
||||
path mapping) with which requests are processed if no other
|
||||
controller method matches more concretely. In the new support
|
||||
classes if a matching method is not found a 404 error
|
||||
is raised.</para></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>The above features are still supported with the existing support
|
||||
classes. However to take advantage of new Spring MVC 3.1 features
|
||||
you'll need to use the new support classes.</para>
|
||||
|
||||
</section>
|
||||
|
||||
<section id="mvc-ann-requestmapping-uri-templates">
|
||||
<title>URI Template Patterns</title>
|
||||
|
||||
@@ -1106,6 +1169,17 @@ public class RelativePathUriTemplateController {
|
||||
<classname>BindingResult</classname> arguments. This is described in the
|
||||
next section.</para>
|
||||
|
||||
<note><para>Spring 3.1 introduced a new set of support classes for
|
||||
<classname>@RequestMapping</classname> methods called
|
||||
<classname>RequestMappingHandlerMapping</classname> and
|
||||
<classname>RequestMappingHandlerAdapter</classname> respectively.
|
||||
They are recommended for use and even required to take advantage
|
||||
of new features in Spring MVC 3.1 and going forward.
|
||||
The new support classes are enabled by default from the MVC namespace and
|
||||
with use of the MVC Java config (<code>@EnableWebMvc</code>) but must be
|
||||
configured explicitly if using neither.
|
||||
</para></note>
|
||||
|
||||
<section id="mvc-ann-arguments">
|
||||
<title>Supported method argument types</title>
|
||||
|
||||
@@ -1503,16 +1577,18 @@ public void handle(@RequestBody String body, Writer writer) throws IOException {
|
||||
<bean id="castorMarshaller" class="org.springframework.oxm.castor.CastorMarshaller"/></programlisting>
|
||||
|
||||
<para>An <classname>@RequestBody</classname> method parameter can be
|
||||
annotated with <classname>@Valid</classname>, in which case it will
|
||||
annotated with <classname>@Valid</classname>, in which case it will be
|
||||
validated using the configured <classname>Validator</classname>
|
||||
instance. When using the MVC namespace a JSR-303 validator is
|
||||
configured automatically assuming a JSR-303 implementation is
|
||||
available on the classpath. If validation fails a
|
||||
<classname>RequestBodyNotValidException</classname> is raised. The
|
||||
exception is handled by the
|
||||
<classname>DefaultHandlerExceptionResolver</classname> and results in
|
||||
a <literal>400</literal> error sent back to the client along with a
|
||||
message containing the validation errors.</para>
|
||||
available on the classpath.</para>
|
||||
<para>Unlike <classname>@ModelAttribute</classname> parameters, for which
|
||||
a <classname>BindingResult</classname> can be used to examine the errors,
|
||||
<classname>@RequestBody</classname> validation errors always result in a
|
||||
<classname>MethodArgumentNotValidException</classname> being raised.
|
||||
The exception is handled in the
|
||||
<classname>DefaultHandlerExceptionResolver</classname>, which sends
|
||||
a <literal>400</literal> error back to the client.</para>
|
||||
|
||||
<note>
|
||||
<para>Also see <xref linkend="mvc-annotation-driven" /> for
|
||||
|
||||
@@ -391,6 +391,10 @@
|
||||
Java-based configuration via <interface>@EnableWebMvc</interface>. The
|
||||
existing classes will continue to be available but use of the new
|
||||
classes is recommended going forward.</para>
|
||||
|
||||
<para>See <xref linkend="mvc-ann-requestmapping-31-vs-30"/> for additional
|
||||
details and a list of features not available with the new support classes.</para>
|
||||
|
||||
</section>
|
||||
|
||||
<section>
|
||||
@@ -483,27 +487,27 @@
|
||||
<section>
|
||||
<title><classname>UriComponentsBuilder</classname> and <classname>UriComponents</classname></title>
|
||||
|
||||
<para>A new <classname>UriComponents</classname> class has been added,
|
||||
which is an immutable container of URI components providing
|
||||
<para>A new <classname>UriComponents</classname> class has been added,
|
||||
which is an immutable container of URI components providing
|
||||
access to all contained URI components.
|
||||
A nenw <classname>UriComponentsBuilder</classname> class is also
|
||||
A nenw <classname>UriComponentsBuilder</classname> class is also
|
||||
provided to help create <classname>UriComponents</classname> instances.
|
||||
Together the two classes give fine-grained control over all
|
||||
aspects of preparing a URI including construction, expansion
|
||||
from URI template variables, and encoding.</para>
|
||||
|
||||
<para>In most cases the new classes can be used as a more flexible
|
||||
alternative to the existing <classname>UriTemplate</classname>
|
||||
|
||||
<para>In most cases the new classes can be used as a more flexible
|
||||
alternative to the existing <classname>UriTemplate</classname>
|
||||
especially since <classname>UriTemplate</classname> relies on those
|
||||
same classes internally.
|
||||
</para>
|
||||
|
||||
|
||||
<para>A <classname>ServletUriComponentsBuilder</classname> sub-class
|
||||
provides static factory methods to copy information from
|
||||
provides static factory methods to copy information from
|
||||
a Servlet request. See <xref linkend="mvc-construct-encode-uri"/>.
|
||||
</para>
|
||||
|
||||
|
||||
</section>
|
||||
|
||||
|
||||
</section>
|
||||
</chapter>
|
||||
|
||||
@@ -1580,7 +1580,7 @@ String body = response.getBody();</programlisting>
|
||||
</section>
|
||||
|
||||
<section id="rest-byte-converter">
|
||||
<title>ByteArrayMessageConverter</title>
|
||||
<title>ByteArrayHttpMessageConverter</title>
|
||||
|
||||
<para>An <interfacename>HttpMessageConverter</interfacename>
|
||||
implementation that can read and write byte arrays from the HTTP
|
||||
|
||||
Reference in New Issue
Block a user