Fix typos in Reference Documentation
This commit is contained in:
@@ -2545,7 +2545,7 @@ public @interface Idempotent {
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para><literal>final</literal> methods cannot be advised, as they
|
||||
cannot be overriden.</para>
|
||||
cannot be overridden.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
|
||||
@@ -144,7 +144,7 @@ public class JpaMovieFinder implements MovieFinder {
|
||||
<note>
|
||||
<para>In Spring 3.0 RC1 you can use JSR 330's
|
||||
<interfacename>@Named</interfacename> annotation in place of
|
||||
stereotpye annotations and they will be automatically detected during
|
||||
stereotype annotations and they will be automatically detected during
|
||||
component-scanning. The value of the
|
||||
<interfacename>@Named</interfacename> property will be used as the
|
||||
Bean Name. At this time Spring defaults for bean scope will be applied
|
||||
|
||||
@@ -224,7 +224,7 @@ The footnote should x-ref to first section in that chapter but I can't find the
|
||||
<para>After you learn about Spring's IoC container, you may want to know
|
||||
more about Spring's <interfacename>Resource</interfacename>
|
||||
abstraction, as described in <xref linkend="resources"/>, which
|
||||
provides a convenient mechanism for reading an InputSream from
|
||||
provides a convenient mechanism for reading an InputStream from
|
||||
locations defined in a URI syntax. In particular,
|
||||
<classname>Resource</classname> paths are used to construct
|
||||
applications contexts as described in <xref
|
||||
|
||||
@@ -98,7 +98,7 @@ public Book findBook(ISBN isbn) {...}]]></programlisting>
|
||||
In fact, depending on the JVM implementation or running conditions, the same hashCode can be reused for different objects, in the same VM instance.</para>
|
||||
|
||||
<para>To provide a different <emphasis>default</emphasis> key generator, one needs to implement the <interfacename>org.springframework.cache.KeyGenerator</interfacename> interface.
|
||||
Once configured, the generator will be used for each declaration that doesn not specify its own key generation strategy (see below).
|
||||
Once configured, the generator will be used for each declaration that does not specify its own key generation strategy (see below).
|
||||
</para>
|
||||
</section>
|
||||
|
||||
@@ -223,11 +223,11 @@ public Book findBook(String name)]]></programlisting>
|
||||
<section id="cache-annotations-put">
|
||||
<title><literal>@CachePut</literal> annotation</title>
|
||||
|
||||
<para>For cases where the cache needs to be updated without interferring with the method execution, one can use the <literal>@CachePut</literal> annotation. That is, the method will always
|
||||
<para>For cases where the cache needs to be updated without interfering with the method execution, one can use the <literal>@CachePut</literal> annotation. That is, the method will always
|
||||
be executed and its result placed into the cache (according to the <literal>@CachePut</literal> options). It supports the same options as <literal>@Cacheable</literal> and should be used
|
||||
for cache population rather then method flow optimization.</para>
|
||||
|
||||
<para>Note that using <literal>@CachePut</literal> and <literal>@Cacheable</literal> annotations on the same method is generaly discouraged because they have different behaviours. While the latter
|
||||
<para>Note that using <literal>@CachePut</literal> and <literal>@Cacheable</literal> annotations on the same method is generally discouraged because they have different behaviours. While the latter
|
||||
causes the method execution to be skipped by using the cache, the former forces the execution in order to execute a cache update. This leads to unexpected behaviour and with the exception of specific
|
||||
corner-cases (such as annotations having conditions that exclude them from each other), such declarations should be avoided.</para>
|
||||
</section>
|
||||
@@ -447,7 +447,7 @@ public Book findBook(ISBN isbn, boolean checkWarehouse, boolean includeUsed)]]><
|
||||
public Book findBook(ISBN isbn, boolean checkWarehouse, boolean includeUsed)]]></programlisting>
|
||||
|
||||
<para>Even though <literal>@SlowService</literal> is not a Spring annotation, the container automatically picks up its declaration at runtime and understands its meaning. Note that as
|
||||
mentined <link linkend="cache-annotation-enable">above</link>, the annotation-driven behaviour needs to be enabled.</para>
|
||||
mentioned <link linkend="cache-annotation-enable">above</link>, the annotation-driven behaviour needs to be enabled.</para>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
@@ -488,7 +488,7 @@ public Book findBook(ISBN isbn, boolean checkWarehouse, boolean includeUsed)]]><
|
||||
<para>The declarative XML caching supports all of the annotation-based model so moving between the two should be fairly easy - further more both can be used inside the same application.
|
||||
The XML based approach does not touch the target code however it is inherently more verbose; when dealing with classes with overloaded methods that are targeted for caching, identifying the
|
||||
proper methods does take an extra effort since the <literal>method</literal> argument is not a good discriminator - in these cases, the AspectJ pointcut can be used to cherry pick the target
|
||||
methods and apply the appropriate caching functionality. Howeve through XML, it is easier to apply a package/group/interface-wide caching (again due to the AspectJ poincut) and to create
|
||||
methods and apply the appropriate caching functionality. However through XML, it is easier to apply a package/group/interface-wide caching (again due to the AspectJ pointcut) and to create
|
||||
template-like definitions (as we did in the example above by defining the target cache through the <literal>cache:definitions </literal><literal>cache</literal> attribute).
|
||||
</para>
|
||||
</section>
|
||||
@@ -554,7 +554,7 @@ public Book findBook(ISBN isbn, boolean checkWarehouse, boolean includeUsed)]]><
|
||||
<property name="addNoOpCache" value="true"/>
|
||||
</bean>]]></programlisting>
|
||||
|
||||
<para>The <literal>CompositeCacheManager</literal> above chains multiple <literal>CacheManager</literal>s and aditionally, through the <literal>addNoOpManager</literal> flag, adds a
|
||||
<para>The <literal>CompositeCacheManager</literal> above chains multiple <literal>CacheManager</literal>s and additionally, through the <literal>addNoOpManager</literal> flag, adds a
|
||||
<emphasis>no op</emphasis> cache that for all the definitions not handled by the configured cache managers. That is, every cache definition not found in either <literal>jdkCache</literal>
|
||||
or <literal>gemfireCache</literal> (configured above) will be handled by the no op cache, which will not store any information causing the target method to be executed every time.
|
||||
</para>
|
||||
|
||||
@@ -1808,7 +1808,7 @@ Object oldTarget = swapper.swap(newTarget);</programlisting></para>
|
||||
<para>Note that the target object - "businessObjectTarget" in the
|
||||
example - <emphasis>must</emphasis> be a prototype. This allows the
|
||||
<literal>PoolingTargetSource</literal> implementation to create new
|
||||
instances of the target to grow the pool as necessary. See the havadoc
|
||||
instances of the target to grow the pool as necessary. See the Javadoc
|
||||
for <literal>AbstractPoolingTargetSource</literal> and the concrete
|
||||
subclass you wish to use for information about its properties: "maxSize"
|
||||
is the most basic, and always guaranteed to be present.</para>
|
||||
|
||||
@@ -688,7 +688,7 @@ boolean trueValue = parser.parseExpression(expression).getValue(societyContext,
|
||||
boolean trueValue = parser.parseExpression("true or false").getValue(Boolean.class);
|
||||
|
||||
// evaluates to true
|
||||
String expression = "isMember('Nikola Tesla') or isMember('Albert Einstien')";
|
||||
String expression = "isMember('Nikola Tesla') or isMember('Albert Einstein')";
|
||||
boolean trueValue = parser.parseExpression(expression).getValue(societyContext, Boolean.class);
|
||||
|
||||
// -- NOT --
|
||||
|
||||
@@ -736,7 +736,7 @@ public Actor findActor(String specialty, int age) {
|
||||
};
|
||||
|
||||
|
||||
<lineannotation>// notice the wrapping up of the argumenta in an array</lineannotation>
|
||||
<lineannotation>// notice the wrapping up of the arguments in an array</lineannotation>
|
||||
return (Actor) jdbcTemplate.queryForObject(sql, new Object[] {specialty, age}, mapper);
|
||||
}</programlisting>
|
||||
|
||||
@@ -813,7 +813,7 @@ public Actor findActor(String specialty, int age) {
|
||||
class="libraryfile">sql-error-codes.xml</filename>. This file is
|
||||
populated with vendor codes and based on the
|
||||
<code>DatabaseProductName</code> taken from the
|
||||
<interfacename>DatabaseMetaData</interfacename>. The codes for the acual
|
||||
<interfacename>DatabaseMetaData</interfacename>. The codes for the actual
|
||||
database you are using are used.<!--what do you mean by *the current* database? --><!--TR: Revised, please review.--></para>
|
||||
|
||||
<para>The <classname>SQLErrorCodeSQLExceptionTranslator</classname>
|
||||
@@ -888,7 +888,7 @@ public Actor findActor(String specialty, int age) {
|
||||
processing where this translator is needed. Here is an example of how
|
||||
this custom translator can be used:</para>
|
||||
|
||||
<programlisting language="java"><lineannotation>private JdbcTemplate jdbcTemoplate;
|
||||
<programlisting language="java"><lineannotation>private JdbcTemplate jdbcTemplate;
|
||||
|
||||
public void setDataSource(DataSource dataSource) {
|
||||
// create a <classname>JdbcTemplate</classname> and set data source</lineannotation>
|
||||
@@ -901,7 +901,7 @@ public void setDataSource(DataSource dataSource) {
|
||||
}
|
||||
|
||||
<lineannotation>public void updateShippingCharge(long orderId, long pct) {
|
||||
// use the <classname>prepared JdbcTemplate</classname> for this u<classname>pdate</classname></lineannotation>
|
||||
// use the <classname>prepared JdbcTemplate</classname> for this <classname>update</classname></lineannotation>
|
||||
this.jdbcTemplate.update(
|
||||
"update orders" +
|
||||
" set shipping_charge = shipping_charge * ? / 100" +
|
||||
@@ -1547,8 +1547,8 @@ dataSource.setPassword("");</programlisting>
|
||||
length indicates the number of updates in that batch. The number of
|
||||
updates in each batch should be the the batch size provided for all
|
||||
batches except for the last one that might be less, depending on the
|
||||
total number of updat objects provided. The update count for each update
|
||||
stament is the one reported by the JDBC driver. If the count is not
|
||||
total number of update objects provided. The update count for each update
|
||||
statement is the one reported by the JDBC driver. If the count is not
|
||||
available, the JDBC driver returns a -2 value.</para>
|
||||
</section>
|
||||
</section>
|
||||
@@ -2501,7 +2501,7 @@ public class TitlesAfterDateStoredProcedure extends StoredProcedure {
|
||||
<para>Many update and query methods of the
|
||||
<classname>JdbcTemplate</classname> take an additional parameter in
|
||||
the form of an <code>int </code>array. This array is used to
|
||||
indicate the SQL type of the coresponding parameter using constant
|
||||
indicate the SQL type of the corresponding parameter using constant
|
||||
values from the <classname>java.sql.Types</classname> class. <!--Reword to say *what* is using constant values from the java.sql.Types class to do *what*. Phrases that being with *using* are --><!--often unclear as to what uses what to do what.-->Provide
|
||||
one entry for each parameter.</para>
|
||||
</listitem>
|
||||
@@ -2983,7 +2983,7 @@ public class DataAccessUnitTestTemplate {
|
||||
<jdbc:script location="..."/>
|
||||
</jdbc:initialize-database></programlisting>In this example we are
|
||||
saying we expect that sometimes the scripts will be run against an empty
|
||||
dtabase and there are some DROP statements in the scripts which would
|
||||
database and there are some DROP statements in the scripts which would
|
||||
therefore fail. So failed SQL <code>DROP</code> statements will be
|
||||
ignored, but other failures will cause an exception. This is useful if
|
||||
your SQL dialect doesn't support <code>DROP ... IF EXISTS</code> (or
|
||||
|
||||
@@ -269,7 +269,7 @@
|
||||
|
||||
</web-app></programlisting>
|
||||
|
||||
<para>In the preceding example, all requests startig with
|
||||
<para>In the preceding example, all requests starting with
|
||||
<literal>/example</literal> will be handled by the
|
||||
<classname>DispatcherServlet</classname> instance named
|
||||
<literal>example</literal>. This is only the first step in setting up
|
||||
@@ -1073,7 +1073,7 @@ public void addPet(@RequestBody Pet pet, Model model) {
|
||||
<para>The <emphasis>consumes</emphasis> condition is supported on
|
||||
the type and on the method level. Unlike most other conditions, when
|
||||
used at the type level, method-level consumable types override
|
||||
rather than extend type-level consumeable types.</para>
|
||||
rather than extend type-level consumable types.</para>
|
||||
</tip>
|
||||
</section>
|
||||
|
||||
@@ -1116,7 +1116,7 @@ public Pet getPet(@PathVariable String petId, Model model) {
|
||||
<para>You can narrow request matching through request parameter
|
||||
conditions such as <code>"myParam"</code>, <code>"!myParam"</code>, or
|
||||
<code>"myParam=myValue"</code>. The first two test for request
|
||||
parameter presense/absence and the third for a specific parameter
|
||||
parameter presence/absence and the third for a specific parameter
|
||||
value. Here is an example with a request parameter value
|
||||
condition:</para>
|
||||
|
||||
@@ -4581,7 +4581,7 @@ public class WebConfig extends WebMvcConfigurerAdapter {
|
||||
<code>DefaultServletHttpRequestHandler</code> will attempt to
|
||||
auto-detect the default Servlet for the container at startup time, using
|
||||
a list of known names for most of the major Servlet containers
|
||||
(including Tomcat, Jetty, Glassfish, JBoss, Resin, WebLogic, and
|
||||
(including Tomcat, Jetty, GlassFish, JBoss, Resin, WebLogic, and
|
||||
WebSphere). If the default Servlet has been custom configured with a
|
||||
different name, or if a different Servlet container is being used where
|
||||
the default Servlet name is unknown, then the default Servlet's name
|
||||
|
||||
@@ -490,7 +490,7 @@
|
||||
<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 new <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
|
||||
|
||||
@@ -427,7 +427,7 @@ TR: OK. Added to diagram.--></para>
|
||||
development snapshots and milestone releases (a copy of the final
|
||||
releases is also held here). The jar file names are in the same
|
||||
form as Maven Central, so this is a useful place to get
|
||||
development versions of Spring to use with other libraries depoyed
|
||||
development versions of Spring to use with other libraries deployed
|
||||
in Maven Central.</para>
|
||||
</listitem>
|
||||
</itemizedlist></para>
|
||||
@@ -615,7 +615,7 @@ TR: OK. Added to diagram.--></para>
|
||||
<para>We used the Maven Central naming conventions in the example
|
||||
above, so that works with Maven Central or the SpringSource S3 Maven
|
||||
repository. To use the S3 Maven repository (e.g. for milestones or
|
||||
developer snaphots), you need to specify the repository location in
|
||||
developer snapshots), you need to specify the repository location in
|
||||
your Maven configuration. For full releases:</para>
|
||||
|
||||
<programlisting><repositories>
|
||||
@@ -670,7 +670,7 @@ TR: OK. Added to diagram.--></para>
|
||||
</repositories></programlisting>
|
||||
|
||||
<para>If you are managing your dependencies by hand, the URL in the
|
||||
repository declaration above is not browseable, but there is a user
|
||||
repository declaration above is not browsable, but there is a user
|
||||
interface at <ulink
|
||||
url="http://www.springsource.com/repository">http://www.springsource.com/repository</ulink>
|
||||
that can be used to search for and download dependencies. It also has
|
||||
@@ -879,8 +879,8 @@ TR: OK. Added to diagram.--></para>
|
||||
and generates fewer dependencies, is to bind directly to <ulink type=""
|
||||
url="http://logback.qos.ch">Logback</ulink>. This removes the extra
|
||||
binding step because Logback implements SLF4J directly, so you only need
|
||||
to depend on two libaries not four (<code>jcl-over-slf4j</code> and
|
||||
<code>logback</code>). If you do that you might also need to exlude the
|
||||
to depend on two libraries not four (<code>jcl-over-slf4j</code> and
|
||||
<code>logback</code>). If you do that you might also need to exclude the
|
||||
slf4j-api dependency from other external dependencies (not Spring),
|
||||
because you only want one version of that API on the classpath.</para>
|
||||
|
||||
|
||||
@@ -518,7 +518,7 @@
|
||||
included here for completeness.</para>
|
||||
|
||||
<para>When using the <classname>AbstractController</classname> as a
|
||||
baseclass for your controllers (which is not recommended since there
|
||||
base class for your controllers (which is not recommended since there
|
||||
are a lot of other controllers that might already do the job for
|
||||
you) you only have to override either the
|
||||
<methodname>handleActionRequestInternal(ActionRequest,
|
||||
|
||||
@@ -1473,7 +1473,7 @@ URI location = template.postForLocation(uri, booking, "1");
|
||||
|
||||
URI uri = uriComponents.toUri();</programlisting>
|
||||
|
||||
<para>Or specify each URI component indiviudally:</para>
|
||||
<para>Or specify each URI component individually:</para>
|
||||
|
||||
<programlisting language="java">UriComponents uriComponents =
|
||||
UriComponentsBuilder.newInstance()
|
||||
|
||||
@@ -651,7 +651,7 @@
|
||||
case, the resolution strategy is fairly simple: a
|
||||
ClassLoader.getResources() call is used on the last non-wildcard path
|
||||
segment to get all the matching resources in the class loader
|
||||
hierarchy, and then off each resource the same PathMatcher resoltion
|
||||
hierarchy, and then off each resource the same PathMatcher resolution
|
||||
strategy described above is used for the wildcard subpath.</para>
|
||||
</section>
|
||||
|
||||
|
||||
@@ -592,7 +592,7 @@ Future<String> returnSomething(int i) {
|
||||
|
||||
<para><interfacename>@Async</interfacename> can not be used in
|
||||
conjunction with lifecycle callbacks such as
|
||||
<interfacename>@PostConstruct</interfacename>. To asynchonously
|
||||
<interfacename>@PostConstruct</interfacename>. To asynchronously
|
||||
initialize Spring beans you currently have to use a separate
|
||||
initializing Spring bean that invokes the
|
||||
<interfacename>@Async</interfacename> annotated method on the target
|
||||
|
||||
@@ -1085,7 +1085,7 @@ public interface ConversionService {
|
||||
</programlisting>
|
||||
|
||||
<para> A default ConversionService can convert between strings, numbers,
|
||||
enums, collections, maps, and other common types. To suppliment or
|
||||
enums, collections, maps, and other common types. To supplement or
|
||||
override the default converters with your own custom converter(s), set
|
||||
the <code>converters</code> property. Property values may implement
|
||||
either of the Converter, ConverterFactory, or GenericConverter
|
||||
@@ -1112,9 +1112,9 @@ public interface ConversionService {
|
||||
</section>
|
||||
|
||||
<section id="core-convert-programmatic-usage">
|
||||
<title>Using a ConversionService programatically</title>
|
||||
<title>Using a ConversionService programmatically</title>
|
||||
|
||||
<para> To work with a ConversionService instance programatically, simply
|
||||
<para> To work with a ConversionService instance programmatically, simply
|
||||
inject a reference to it like you would for any other bean: </para>
|
||||
|
||||
<programlisting language="java"><![CDATA[@Service
|
||||
@@ -1353,10 +1353,10 @@ public interface AnnotationFormatterFactory<A extends Annotation> {
|
||||
<para> The FormatterRegistry is an SPI for registering formatters and
|
||||
converters. <classname>FormattingConversionService</classname> is
|
||||
an implementation of FormatterRegistry suitable for most environments.
|
||||
This implementation may be configured programatically or declaratively
|
||||
This implementation may be configured programmatically or declaratively
|
||||
as a Spring bean using
|
||||
<classname>FormattingConversionServiceFactoryBean</classname>.
|
||||
Because this implemementation also implements
|
||||
Because this implementation also implements
|
||||
<classname>ConversionService</classname>, it can be directly
|
||||
configured for use with Spring's DataBinder and the Spring Expression
|
||||
Language (SpEL).
|
||||
@@ -1419,7 +1419,7 @@ public interface FormatterRegistrar {
|
||||
<title>Configuring Formatting in Spring MVC</title>
|
||||
|
||||
<para> In a Spring MVC application, you may configure a custom
|
||||
ConversionService instance explicity as an attribute of the
|
||||
ConversionService instance explicitly as an attribute of the
|
||||
<literal>annotation-driven</literal> element of the MVC namespace. This
|
||||
ConversionService will then be used anytime a type conversion is
|
||||
required during Controller model binding. If not configured explicitly,
|
||||
@@ -1443,7 +1443,7 @@ public interface FormatterRegistrar {
|
||||
|
||||
</beans>]]></programlisting>
|
||||
|
||||
<para> With this one-line of configuation, default formatters for Numbers
|
||||
<para> With this one-line of configuration, default formatters for Numbers
|
||||
and Date types will be installed, including support for the
|
||||
@NumberFormat and @DateTimeFormat annotations. Full support for the Joda
|
||||
Time formatting library is also installed if Joda Time is present on the
|
||||
@@ -1503,7 +1503,7 @@ public interface FormatterRegistrar {
|
||||
|
||||
<para> Spring 3 introduces several enhancements to its validation support.
|
||||
First, the JSR-303 Bean Validation API is now fully supported. Second,
|
||||
when used programatically, Spring's DataBinder can now validate objects as
|
||||
when used programmatically, Spring's DataBinder can now validate objects as
|
||||
well as bind to them. Third, Spring MVC now has support for declaratively
|
||||
validating @Controller inputs. </para>
|
||||
|
||||
@@ -1671,7 +1671,7 @@ public class MyConstraintValidator implements ConstraintValidator {
|
||||
<code>binder.validate()</code>. Any validation Errors are automatically
|
||||
added to the binder's BindingResult. </para>
|
||||
|
||||
<para> When working with the DataBinder programatically, this can be used
|
||||
<para> When working with the DataBinder programmatically, this can be used
|
||||
to invoke validation logic after binding to a target object: </para>
|
||||
|
||||
<programlisting language="java">Foo target = new Foo();
|
||||
|
||||
@@ -624,7 +624,7 @@
|
||||
|
||||
<para>
|
||||
<quote>
|
||||
<emphasis>A very succesful design pattern in Tapestry is to keep pages
|
||||
<emphasis>A very successful design pattern in Tapestry is to keep pages
|
||||
and components very simple, and <emphasis
|
||||
role="bold">delegate</emphasis> as much logic as possible out to
|
||||
HiveMind [or Spring, or whatever] services. Listener methods should
|
||||
|
||||
@@ -225,7 +225,7 @@ public class SimpleDateFormatBeanDefinitionParser extends AbstractSingleBeanDefi
|
||||
properties files. These properties files are both placed in a
|
||||
<filename class="directory">'META-INF'</filename> directory in your application, and can, for
|
||||
example, be distributed alongside your binary classes in a JAR file. The Spring XML parsing
|
||||
infrastructurewill automatically pick up your new extension by consuming these special
|
||||
infrastructure will automatically pick up your new extension by consuming these special
|
||||
properties files, the formats of which are detailed below.</para>
|
||||
<section id="extensible-xml-registration-spring-handlers">
|
||||
<title><filename>'META-INF/spring.handlers'</filename></title>
|
||||
|
||||
@@ -125,7 +125,7 @@ http://www.springframework.org/schema/beans http://www.springframework.org/schem
|
||||
implementation, the <classname>FieldRetrievingFactoryBean</classname>, to
|
||||
set the value of the <literal>'isolation'</literal> property on a bean
|
||||
to the value of the <literal>'java.sql.Connection.TRANSACTION_SERIALIZABLE'</literal>
|
||||
constant. This is all well and good, but it is a tad verbose and (unneccessarily)
|
||||
constant. This is all well and good, but it is a tad verbose and (unnecessarily)
|
||||
exposes Spring's internal plumbing to the end user.
|
||||
</para>
|
||||
<para>The following XML Schema-based version is more concise
|
||||
@@ -771,7 +771,7 @@ http://www.springframework.org/schema/beans http://www.springframework.org/schem
|
||||
<interfacename>@Resource</interfacename> (if available), and JPA's
|
||||
<interfacename>@PersistenceContext</interfacename> and <interfacename>@PersistenceUnit</interfacename>
|
||||
(if available). Alternatively, you can choose to activate the individual
|
||||
<interfacename>BeanPostProcessors</interfacename> for those annotations explictly.</para>
|
||||
<interfacename>BeanPostProcessors</interfacename> for those annotations explicitly.</para>
|
||||
<note>
|
||||
<para>This element does <emphasis>not</emphasis> activate processing of Spring's
|
||||
<link linkend="transaction-declarative-annotations"><interfacename>@Transactional</interfacename></link>
|
||||
|
||||
Reference in New Issue
Block a user