root
/
spring-framework
mirror of https://github.com/spring-projects/spring-framework.git
1
0
Fork 0
Code Issues Actions Packages Projects Releases Wiki Activity

Review recent documentation and default servlet changes 

- Relocate and fix typos in interface-based @RequestMapping tip (SPR-7537)
- Fix typos in constructor-arg 'name' disambiguation section (SPR-7443)
- Polish whitespace in DefaultServletHttpRequestHandler (SPR-7553)
This commit is contained in:
Chris Beams 2010-09-15 08:45:21 +00:00
parent c1d2c36f32
commit 562747ef41
3 changed files with 26 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
spring-framework-reference/src/beans-dependencies.xml
View File

@ -171,7 +171,7 @@ public class ExampleBean {
&lt;/bean&gt;</programlisting> &lt;/bean&gt;</programlisting>
<para>Keep in mind that to make this work out of the box your code <para>Keep in mind that to make this work out of the box your code
has to be compiled with the debug flag enabled so that Spring can must be compiled with the debug flag enabled so that Spring can
look up the parameter name from the constructor. If you can't compile look up the parameter name from the constructor. If you can't compile
your code with debug flag (or don't want to) you can use your code with debug flag (or don't want to) you can use
<interfacename><ulink <interfacename><ulink

31
spring-framework-reference/src/mvc.xml
View File

@ -667,18 +667,6 @@ public class HelloWorldController {
&lt;/beans&gt;</programlisting> &lt;/beans&gt;</programlisting>
<para>A common pitfall when working with annotated controller classes is
a scenario where you want apply functionality to it that involves
creating a proxy for the controller object (transactional controllers
e.g.). Usually you will introduce an interface for the controller then
to use JDK dynamic proxies. To make this work you have to move the
<interfacename>@RequestMapping</interfacename> annotations to the
interface as well as the mapping lookup only "sees" the interface
exposed by the proxy then. An alternative might be to activate
<code>proxy-target-class="true"</code> in the configuration for the
functionality applied to the controller (in our transaction scenario in
<code>&lt;tx:annotation-driven /&gt;</code>). For more information on
various proxying mechanisms see <xref linkend="aop-proxying" />.</para>
</section> </section>
<section id="mvc-ann-requestmapping"> <section id="mvc-ann-requestmapping">
@ -777,6 +765,25 @@ public class ClinicController {
}</programlisting> }</programlisting>
<tip>
<title>Working with interface-based @Controller classes</title>
<para>A common pitfall when working with annotated controller classes
happens when applying functionality that requires creating a proxy
proxy for the controller object (e.g.
<interfacename>@Transactional</interfacename> methods). Usually you
will introduce an interface for the controller in order to use JDK
dynamic proxies. To make this work you must move the
<interfacename>@RequestMapping</interfacename> annotations to the
interface as as the mapping mechanism can only "see" the interface
exposed by the proxy. As an alternative, you may choose to activate
<code>proxy-target-class="true"</code> in the configuration for the
functionality applied to the controller (in our transaction scenario
in <code>&lt;tx:annotation-driven /&gt;</code>). Doing so indicates
that CGLIB-based subclass proxies should be used instead of
interface-based JDK proxies. For more information on various proxying
mechanisms see <xref linkend="aop-proxying"/>.</para>
</tip>
<section id="mvc-ann-requestmapping-uri-templates"> <section id="mvc-ann-requestmapping-uri-templates">
<title>URI Templates</title> <title>URI Templates</title>