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:
Chris Beams
2012-02-13 15:17:30 +01:00
134 changed files with 3552 additions and 1471 deletions

View File

@@ -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 {

View File

@@ -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

View File

@@ -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 {
&lt;bean id="castorMarshaller" class="org.springframework.oxm.castor.CastorMarshaller"/&gt;</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

View File

@@ -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>

View File

@@ -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