Fix typos (SPR-7339)
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@3536 50f2f4bb-b051-0410-bef5-90022cba6387
This commit is contained in:
parent
d1fbb74a74
commit
9d514b6d59
|
|
@ -468,8 +468,8 @@ private void anyOldTransfer() {}<lineannotation>// the pointcut signature</linea
|
|||
<classname>IllegalArgumentException</classname> being thrown.</para>
|
||||
|
||||
<para>The set of pointcut designators supported by Spring AOP may be
|
||||
extended in future releases both to support more of the AspectJ
|
||||
pointcut designators.</para>
|
||||
extended in future releases to support more of the AspectJ pointcut
|
||||
designators.</para>
|
||||
</sidebar>
|
||||
|
||||
<itemizedlist>
|
||||
|
|
|
|||
|
|
@ -592,8 +592,8 @@ List userList service.getUsernameList();
|
|||
always adequate, however. It is sometimes desirable to introduce an
|
||||
alias for a bean that is defined elsewhere. This is commonly the case
|
||||
in large systems where configuration is split amongst each subsystem,
|
||||
each subsystem having its own set of object defintions. In XML-based
|
||||
configuration metadata, you can use of the
|
||||
each subsystem having its own set of object definitions. In XML-based
|
||||
configuration metadata, you can use the
|
||||
<literal><alias/></literal> element to accomplish this.</para>
|
||||
|
||||
<programlisting language="xml"><alias name="fromName" alias="toName"/></programlisting>
|
||||
|
|
@ -1994,14 +1994,14 @@ support=support@example.co.uk</programlisting>
|
|||
during development, without negating the option of switching to
|
||||
explicit wiring when the code base becomes more stable.</para>
|
||||
</listitem>
|
||||
</itemizedlist><footnote>
|
||||
<para>See <xref linkend="beans-factory-collaborators" /></para>
|
||||
</footnote> When using XML-based configuration metadata, you specify
|
||||
autowire mode for a bean definition with the <literal>autowire</literal>
|
||||
attribute of the <literal><bean/></literal> element. The
|
||||
autowiring functionality has five modes. You specify autowiring
|
||||
<emphasis>per</emphasis> bean and thus can choose which ones to
|
||||
autowire.</para>
|
||||
</itemizedlist>
|
||||
When using XML-based configuration metadata<footnote><para>See
|
||||
<xref linkend="beans-factory-collaborators" /></para></footnote>, you
|
||||
specify autowire mode for a bean definition with the
|
||||
<literal>autowire</literal> attribute of the
|
||||
<literal><bean/></literal> element. The autowiring functionality has
|
||||
five modes. You specify autowiring <emphasis>per</emphasis> bean and thus
|
||||
can choose which ones to autowire.</para>
|
||||
|
||||
<table id="beans-factory-autowiring-modes-tbl">
|
||||
<title>Autowiring modes</title>
|
||||
|
|
@ -4544,9 +4544,9 @@ dataSource.url=jdbc:mysql:mydb</programlisting>
|
|||
|
||||
<para>An alternative to XML setups is provided by annotation-based
|
||||
configuration which rely on the bytecode metadata for wiring up components
|
||||
instead on angle-bracket declarations. Instead of using XML to describe a
|
||||
instead of angle-bracket declarations. Instead of using XML to describe a
|
||||
bean wiring, the developer moves the configuration into the component
|
||||
class itself by using annotations on relevant class, method or field
|
||||
class itself by using annotations on the relevant class, method, or field
|
||||
declaration. As mentioned in <xref
|
||||
linkend="beans-factory-extension-bpp-examples-rabpp" />, using a
|
||||
<interfacename>BeanPostProcessor</interfacename> in conjunction with
|
||||
|
|
|
|||
|
|
@ -223,7 +223,7 @@ http://www.springframework.org/schema/lang http://www.springframework.org/schema
|
|||
</sidebar>
|
||||
<para>
|
||||
The final step involves defining dynamic-language-backed bean definitions,
|
||||
one for each bean that you want to configure (this is no different to
|
||||
one for each bean that you want to configure (this is no different from
|
||||
normal JavaBean configuration). However, instead of specifying the
|
||||
fully qualified classname of the class that is to be instantiated and
|
||||
configured by the container, you use the <literal><lang:language/></literal>
|
||||
|
|
|
|||
|
|
@ -279,7 +279,8 @@ public void setMyComponent(MyComponent myComponent) {
|
|||
</para>
|
||||
<para>
|
||||
Consider an example Stateless Session bean which actually delegates
|
||||
the implementation to a plain java service object. We have the business interface:
|
||||
the implementation to a plain java service object. We have the business
|
||||
interface:
|
||||
</para>
|
||||
<programlisting language="java"><![CDATA[public interface MyComponent {
|
||||
public void myMethod(...);
|
||||
|
|
@ -335,24 +336,27 @@ public void setMyComponent(MyComponent myComponent) {
|
|||
passivated and reactivated as part of their lifecycle, and which use a
|
||||
non-serializable container instance (which is the normal case) will have
|
||||
to manually call <literal>unloadBeanFactory()</literal> and
|
||||
<literal>loadBeanFactory</literal> from <literal>ejbPassivate</literal>
|
||||
and <literal>ejbActivate</literal>, respectively, to unload and reload the
|
||||
<literal>loadBeanFactory()</literal> from <literal>ejbPassivate()</literal>
|
||||
and <literal>ejbActivate()</literal>, respectively, to unload and reload the
|
||||
BeanFactory on passivation and activation, since it can not be saved by
|
||||
the EJB container.
|
||||
</para>
|
||||
<para>
|
||||
The default behavior of the <classname>ContextJndiBeanFactoryLocator</classname>
|
||||
classes which is to load an <classname>ApplicationContext</classname> for the
|
||||
use of the EJB is adequate for some situations. However, it is problematic when
|
||||
the <classname>ApplicationContext</classname> is loading a number
|
||||
of beans, or the initialization of those beans is time consuming or memory
|
||||
intensive (such as a Hibernate <classname>SessionFactory</classname> initialization, for
|
||||
example), since every EJB will have their own copy. In this case, the user
|
||||
may want to override the default <classname>ContextJndiBeanFactoryLocator</classname>
|
||||
usage and use another <classname>BeanFactoryLocator</classname> variant, such as the
|
||||
<classname>ContextSingletonBeanFactoryLocator</classname> which can load and use a
|
||||
shared container to be used by multiple EJBs or other clients. Doing this is relatively
|
||||
simple, by adding code similar to this to the EJB:
|
||||
The default behavior of the
|
||||
<classname>ContextJndiBeanFactoryLocator</classname> class is to load an
|
||||
<classname>ApplicationContext</classname> for use by an EJB, and is
|
||||
adequate for some situations. However, it is problematic when the
|
||||
<classname>ApplicationContext</classname> is loading a number of beans,
|
||||
or the initialization of those beans is time consuming or memory
|
||||
intensive (such as a Hibernate <classname>SessionFactory</classname>
|
||||
initialization, for example), since every EJB will have their own copy.
|
||||
In this case, the user may want to override the default
|
||||
<classname>ContextJndiBeanFactoryLocator</classname> usage and use
|
||||
another <classname>BeanFactoryLocator</classname> variant, such as the
|
||||
<classname>ContextSingletonBeanFactoryLocator</classname> which can load
|
||||
and use a shared container to be used by multiple EJBs or other clients.
|
||||
Doing this is relatively simple, by adding code similar to this to the
|
||||
EJB:
|
||||
</para>
|
||||
<programlisting language="java"><![CDATA[ /**
|
||||
* Override default BeanFactoryLocator implementation
|
||||
|
|
|
|||
|
|
@ -829,7 +829,7 @@ public Actor findActor(String specialty, int age) {
|
|||
</note>
|
||||
|
||||
<listitem>
|
||||
<para>Any a custom translation implemented by a subclass. Normally
|
||||
<para>Any custom translation implemented by a subclass. Normally
|
||||
the provided concrete
|
||||
<classname>SQLErrorCodeSQLExceptionTranslator</classname> is used
|
||||
so this rule does not apply. It only applies if you have actually
|
||||
|
|
@ -1715,7 +1715,7 @@ END;</programlisting>The <code>in_id</code> parameter contains the
|
|||
<para>The <classname>SimpleJdbcCall</classname> is declared in a similar
|
||||
manner to the <classname>SimpleJdbcInsert</classname>. You should
|
||||
instantiate and configure the class in the initialization method of your
|
||||
data access layer. Compared to the StoredProcdedure class, you don't
|
||||
data access layer. Compared to the StoredProcedure class, you don't
|
||||
have to create a subclass and you don't have to declare parameters that
|
||||
can be looked up in the database metadata. <!--Reword preceding: You need not subclass *what?* and you declare *what* in init method? TR: Revised, pplease review.-->Following
|
||||
is an example of a SimpleJdbcCall configuration using the above stored
|
||||
|
|
@ -2134,7 +2134,7 @@ public Customer getCustomer(Long id) {
|
|||
<para>The method in this example retrieves the customer with the id that
|
||||
is passed in as the only parameter. Since we only want one object
|
||||
returned we simply call the convenience method <code>findObject</code>
|
||||
with the id as parameter. If we instead had a query the returned a list
|
||||
with the id as parameter. If we had instead a query that returned a list
|
||||
of objects and took additional parameters then we would use one of the
|
||||
execute methods that takes an array of parameter values passed in as
|
||||
varargs.</para>
|
||||
|
|
@ -2476,9 +2476,9 @@ public class TitlesAfterDateStoredProcedure extends StoredProcedure {
|
|||
of these approaches use an implementation of the
|
||||
<classname>LobHandler</classname> interface for the actual management of
|
||||
the LOB data. The <classname>LobHandler</classname> provides access to a
|
||||
<classname>LobCreator</classname><!--a LobCreator *what*? Say what it is. TR: Revised.-->class,
|
||||
through the <classname>getLobCreator</classname> method, used for
|
||||
creating new LOB objects to be inserted.</para>
|
||||
<classname>LobCreator</classname> class, through the
|
||||
<classname>getLobCreator</classname> method, used for creating new LOB
|
||||
objects to be inserted.</para>
|
||||
|
||||
<para>The <classname>LobCreator/LobHandler</classname> provides the
|
||||
following support for LOB input and output:</para>
|
||||
|
|
@ -2577,14 +2577,14 @@ clobReader.close();</programlisting>
|
|||
|
||||
<callout arearefs="jdbc.lobhandler.setBlob">
|
||||
<para>Using the method
|
||||
<classname>setBlobAsBinartStream</classname>, pass in the contents
|
||||
<classname>setBlobAsBinaryStream</classname>, pass in the contents
|
||||
of the BLOB.</para>
|
||||
</callout>
|
||||
</calloutlist>
|
||||
</programlistingco>
|
||||
|
||||
<para>Now it's time to read the LOB data from the database. Again, you
|
||||
use a <code>JdbcTempate</code> with the same instance variable
|
||||
use a <code>JdbcTemplate</code> with the same instance variable
|
||||
<code>l</code><code>obHandler </code>and a reference to a
|
||||
<classname>DefaultLobHandler</classname>.</para>
|
||||
|
||||
|
|
@ -2892,7 +2892,7 @@ public class DataAccessUnitTestTemplate {
|
|||
|
||||
<para>If you want to initialize a database and you can provide a
|
||||
reference to a DataSource bean, use the
|
||||
<literal>initialize-datasource</literal> tag in the
|
||||
<literal>initialize-database</literal> tag in the
|
||||
<literal>spring-jdbc</literal> namespace:</para>
|
||||
|
||||
<programlisting><jdbc:initialize-database data-source="dataSource">
|
||||
|
|
@ -2916,11 +2916,12 @@ public class DataAccessUnitTestTemplate {
|
|||
the tables first and then inserts the data - the first step will fail if
|
||||
the tables already exist.</para>
|
||||
|
||||
<para>However, to get more control the creation and deletion of existing
|
||||
data the XML namespace provides a couple more options. The first is flag
|
||||
to switch the initialization on and off. This can be set according to
|
||||
the environment (e.g. to pull a boolean value from system properties or
|
||||
an environment bean), e.g.<programlisting><jdbc:initialize-database data-source="dataSource"
|
||||
<para>However, to get more control over the creation and deletion of
|
||||
existing data, the XML namespace provides a couple more options. The
|
||||
first is flag to switch the initialization on and off. This can be set
|
||||
according to the environment (e.g. to pull a boolean value from system
|
||||
properties or an environment bean), e.g.
|
||||
<programlisting><jdbc:initialize-database data-source="dataSource"
|
||||
<emphasis role="bold">enabled="#{systemProperties.INITIALIZE_DATABASE}"</emphasis>>
|
||||
<jdbc:script location="..."/>
|
||||
</jdbc:initialize-database></programlisting></para>
|
||||
|
|
|
|||
|
|
@ -403,14 +403,14 @@ public class JmsQueueSender {
|
|||
to create a text message from the supplied <classname>Session</classname>
|
||||
object. The <classname>JmsTemplate</classname> is constructed by passing a
|
||||
reference to a <classname>ConnectionFactory</classname>. As an alternative,
|
||||
a zero argument constructor and <property>connectionFactory</property> /
|
||||
a zero argument constructor and <property>connectionFactory</property>
|
||||
is provided and can be used for constructing the instance in JavaBean style
|
||||
(using a BeanFactory or plain Java code). Alternatively, consider deriving
|
||||
from Spring's <classname>JmsGatewaySupport</classname> convenience base class,
|
||||
which provides pre-built bean properties for JMS configuration.</para>
|
||||
|
||||
<para>The method <methodname>send(String destinationName, MessageCreator
|
||||
creator)</methodname> lets you send to a message using the string name of
|
||||
creator)</methodname> lets you send a message using the string name of
|
||||
the destination. If these names are registered in JNDI, you should set the
|
||||
<property>destinationResolver</property> property of the template to an
|
||||
instance of <classname>JndiDestinationResolver</classname>.</para>
|
||||
|
|
@ -444,7 +444,7 @@ public class JmsQueueSender {
|
|||
<para>The sandbox currently includes a
|
||||
<classname>MapMessageConverter</classname> which uses reflection to
|
||||
convert between a JavaBean and a <classname>MapMessage</classname>.
|
||||
Other popular implementations choices you might implement yourself are
|
||||
Other popular implementation choices you might implement yourself are
|
||||
Converters that use an existing XML marshalling package, such as JAXB,
|
||||
Castor, XMLBeans, or XStream, to create a
|
||||
<interfacename>TextMessage</interfacename> representing the
|
||||
|
|
@ -500,7 +500,7 @@ public class JmsQueueSender {
|
|||
<interfacename>ProducerCallback</interfacename> expose the JMS
|
||||
<interfacename>Session</interfacename> and
|
||||
<interfacename>Session</interfacename> /
|
||||
<interfacename>MessageProducer</interfacename> pair respectfully. The
|
||||
<interfacename>MessageProducer</interfacename> pair respectively. The
|
||||
<methodname>execute()</methodname> methods on
|
||||
<classname>JmsTemplate</classname> execute these callback
|
||||
methods.</para>
|
||||
|
|
@ -589,7 +589,7 @@ public class ExampleListener implements MessageListener {
|
|||
|
||||
<para>The <interfacename>SessionAwareMessageListener</interfacename>
|
||||
interface is a Spring-specific interface that provides a similar
|
||||
contract the JMS <interfacename>MessageListener</interfacename>
|
||||
contract to the JMS <interfacename>MessageListener</interfacename>
|
||||
interface, but also provides the message handling method with access to
|
||||
the JMS <interfacename>Session</interfacename> from which the
|
||||
<interfacename>Message</interfacename> was received.</para>
|
||||
|
|
|
|||
|
|
@ -519,7 +519,7 @@ public class AnnotationTestBean implements IJmxTestBean {
|
|||
<literal>add(int, int)</literal>, when using the
|
||||
<classname>MetadataMBeanInfoAssembler</classname>.</para>
|
||||
|
||||
<para>The configuration below shouws how you configure the
|
||||
<para>The configuration below shows how you configure the
|
||||
<classname>MBeanExporter</classname> to use the
|
||||
<classname>MetadataMBeanInfoAssembler</classname>:</para>
|
||||
<programlisting language="xml"><![CDATA[<beans>
|
||||
|
|
|
|||
|
|
@ -210,7 +210,7 @@ sender.send(message);]]></programlisting>
|
|||
<section id="mail-javamail-mime-attachments">
|
||||
<title>Sending attachments and inline resources</title>
|
||||
<para>Multipart email messages allow for both attachments and inline resources.
|
||||
Examples of inline resources would be be images or a stylesheet you want to use
|
||||
Examples of inline resources would be images or a stylesheet you want to use
|
||||
in your message, but that you don't want displayed as an attachment.</para>
|
||||
<section id="mail-javamail-mime-attachments-attachment">
|
||||
<title>Attachments</title>
|
||||
|
|
@ -268,7 +268,7 @@ sender.send(message);]]></programlisting>
|
|||
</section>
|
||||
<section id="mail-templates">
|
||||
<title>Creating email content using a templating library</title>
|
||||
<para>The code in the previous examples explicitly has been creating the
|
||||
<para>The code in the previous examples explicitly created the
|
||||
content of the email message, using methods calls such as
|
||||
<methodname>message.setText(..)</methodname>. This is fine for
|
||||
simple cases, and it is okay in the context of the aforementioned
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ public class PetStoreImpl implements PetStoreFacade, OrderService {</programlist
|
|||
from program source code, some important enterprise settings - notably
|
||||
transaction characteristics - arguably belong in program source.</para>
|
||||
|
||||
<para>Spring uses Java 5 annotations thoughout the framework and across a
|
||||
<para>Spring uses Java 5 annotations throughout the framework and across a
|
||||
wide range of features such as DI, MVC, and AOP and supports standardized
|
||||
annotations such as @PreDestroy and @PostConstruct specified by JSR-250, and
|
||||
@Inject specified by JSR-330. This chapter describes the @Required annotation
|
||||
|
|
|
|||
|
|
@ -820,7 +820,7 @@ public String findOwner(<emphasis role="bold">@PathVariable</emphasis> String ow
|
|||
<!-- MLP: Bev Review -->
|
||||
<para>The matching of method parameter names to URI Template variable
|
||||
names can only be done if your code is compiled with debugging
|
||||
enabled. If you do have not debugging enabled, you must specify the
|
||||
enabled. If you do not have debugging enabled, you must specify the
|
||||
name of the URI Template variable name in the @PathVariable annotation
|
||||
in order to bind the resolved value of the variable name to a method
|
||||
parameter. For example:</para>
|
||||
|
|
@ -1176,8 +1176,9 @@ public String processSubmit(<emphasis role="bold">@ModelAttribute("pet") Pet pet
|
|||
<listitem>
|
||||
<para>A <classname>HttpEntity<?></classname> or
|
||||
<classname>ResponseEntity<?></classname> object
|
||||
to access to the Servlet reponse HTTP headers and contents. The entity body will
|
||||
be converted to the response stream using
|
||||
to provide access to the Servlet reponse HTTP headers and
|
||||
contents. The entity body will be converted to the response
|
||||
stream using
|
||||
<interfacename>HttpMessageConverter</interfacename>s. See <xref
|
||||
linkend="mvc-ann-httpentity" />.</para>
|
||||
</listitem>
|
||||
|
|
@ -2241,7 +2242,7 @@ public class TimeBasedAccessInterceptor extends HandlerInterceptorAdapter {
|
|||
representation of the current resource regardless of the logical view
|
||||
name. The <literal>Accept</literal> header may include wildcards, for
|
||||
example text/*, in which case a <classname>View</classname> whose
|
||||
Context-Type was text/xml is a compatible match.</para>
|
||||
Content-Type was text/xml is a compatible match.</para>
|
||||
|
||||
<para>To support the resolution of a view based on a file extension, use
|
||||
the <classname>ContentNegotiatingViewResolver </classname>bean property
|
||||
|
|
@ -2760,7 +2761,7 @@ public class FileUpoadController {
|
|||
<literal>web.xml</literal>. However, they provide a more flexible way to
|
||||
handle exceptions. They provide information about which handler was
|
||||
executing when the exception was thrown. Furthermore, a programmatic way
|
||||
of handling exception gives you more options for responding
|
||||
of handling exceptions gives you more options for responding
|
||||
appropriately before the request is forwarded to another URL (the same
|
||||
end result as when you use the servlet specific exception
|
||||
mappings).</para>
|
||||
|
|
|
|||
|
|
@ -1367,7 +1367,7 @@ TR: REVISED, PLS REVIEW.-->The factory bean uses the JPA
|
|||
configuration and is appropriate for environments where fine-grained
|
||||
customization is required. The
|
||||
<classname>LocalContainerEntityManagerFactoryBean</classname> creates
|
||||
a <interfacename>PersistenceUnitInfo</interfacename> instance<!--A PersistenceUnitInfo *what*? TR: REVISED, PLS REVIEW. Added *instance*. -->based
|
||||
a <interfacename>PersistenceUnitInfo</interfacename> instance based
|
||||
on the <literal>persistence.xml</literal> file, the supplied
|
||||
<literal>dataSourceLookup</literal> strategy, and the specified
|
||||
<literal>loadTimeWeaver</literal>. It is thus possible to work with
|
||||
|
|
@ -1467,7 +1467,7 @@ TR: OK AS IS. The requirement is to provide the classloader for the runtime envi
|
|||
applied only <emphasis>per class loader</emphasis> and not per
|
||||
VM.</para>
|
||||
|
||||
<para>Refer to the section <xref linkend="aop-aj-ltw-spring" /> in the AOP chapter for more insight regarding the
|
||||
<para>Refer to <xref linkend="aop-aj-ltw-spring" /> in the AOP chapter for more insight regarding the
|
||||
<interfacename>LoadTimeWeaver</interfacename> implementations and their setup, either generic or customized to
|
||||
various platforms (such as Tomcat, WebLogic, OC4J, GlassFish, Resin and JBoss).</para>
|
||||
|
||||
|
|
|
|||
|
|
@ -573,7 +573,7 @@ public class Application {
|
|||
<para>
|
||||
The <classname>JibxMarshaller</classname> class implements both the
|
||||
<interfacename>Marshaller</interfacename> and <interfacename>Unmarshaller</interfacename> interface.
|
||||
To operate, it requires the name of the class to marshall in, which you can set using the
|
||||
To operate, it requires the name of the class to marshal in, which you can set using the
|
||||
<property>targetClass</property> property. Optionally, you can set the binding name using the
|
||||
<property>bindingName</property> property. In the next sample, we bind the
|
||||
<classname>Flights</classname> class:
|
||||
|
|
|
|||
|
|
@ -394,8 +394,8 @@ public class AccountServiceImpl implements AccountService {
|
|||
<title>Exposing the service object</title>
|
||||
|
||||
<para>Setting up the HTTP invoker infrastructure for a service object
|
||||
much resembles the way you would do using Hessian or Burlap. Just as
|
||||
Hessian support provides the
|
||||
resembles closely the way you would do the same using Hessian or Burlap.
|
||||
Just as Hessian support provides the
|
||||
<classname>HessianServiceExporter</classname>, Spring's HttpInvoker
|
||||
support provides the
|
||||
<classname>org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter</classname>.</para>
|
||||
|
|
@ -1280,7 +1280,7 @@ public class Client {
|
|||
<classname>RestTemplate</classname>'s behavior is customized by providing
|
||||
callback methods and configuring the
|
||||
<interfacename>HttpMessageConverter</interfacename> used to marshal
|
||||
objects into the HTTP request body and to unmarshall any response back
|
||||
objects into the HTTP request body and to unmarshal any response back
|
||||
into an object. As it is common to use XML as a message format, Spring
|
||||
provides a <classname>MarshallingHttpMessageConverter</classname> that
|
||||
uses the Object-to-XML framework that is part of the
|
||||
|
|
|
|||
|
|
@ -726,7 +726,7 @@ public class ExampleJob extends QuartzJobBean {
|
|||
<title>Wiring up jobs using triggers and the <classname>SchedulerFactoryBean</classname></title>
|
||||
<para>
|
||||
We've created job details and jobs. We've also reviewed the convenience bean
|
||||
that allows to you invoke a method on a specific object. Of course, we still need
|
||||
that allows you to invoke a method on a specific object. Of course, we still need
|
||||
to schedule the jobs themselves. This is done using triggers and a
|
||||
<classname>SchedulerFactoryBean</classname>. Several triggers are available
|
||||
within Quartz. Spring offers two subclassed triggers with convenient defaults:
|
||||
|
|
@ -870,4 +870,4 @@ public class ExampleJob extends QuartzJobBean {
|
|||
</section>
|
||||
</section>
|
||||
|
||||
</chapter>
|
||||
</chapter>
|
||||
|
|
|
|||
|
|
@ -354,10 +354,9 @@ TR:REVISED, PLS REVIEW-->
|
|||
<property name="password" value="${jdbc.password}" />
|
||||
</bean></programlisting>
|
||||
|
||||
<para>The related <interfacename>The
|
||||
PlatformTransactionManager</interfacename> bean definition will then have
|
||||
a reference to the <interfacename>DataSource</interfacename> definition.
|
||||
It will look like this:</para>
|
||||
<para>The related <interfacename>PlatformTransactionManager</interfacename>
|
||||
bean definition will then have a reference to the
|
||||
<interfacename>DataSource</interfacename> definition. It will look like this:</para>
|
||||
|
||||
<programlisting language="xml"><bean id="txManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
|
||||
<property name="dataSource" ref="dataSource"/>
|
||||
|
|
@ -629,7 +628,7 @@ TR: REVISED, PLS REVIEW - rewrote this to hoefully make it more clear--></para>
|
|||
<para>The Spring Framework enables you to customize transactional
|
||||
behavior, by using AOP. For example, you can insert custom behavior in
|
||||
the case of transaction rollback. You can also add arbitrary advice,
|
||||
along with the transactional advice. With EJB CMT, cannot influence
|
||||
along with the transactional advice. With EJB CMT, you cannot influence
|
||||
the container's transaction management except with
|
||||
<methodname>setRollbackOnly()</methodname>.</para>
|
||||
</listitem>
|
||||
|
|
@ -1858,7 +1857,7 @@ TR: REVISED, PLS REVIEW - changed it back; it's not just settings, the section d
|
|||
<para>When the propagation setting is
|
||||
<literal>PROPAGATION_REQUIRED</literal>, a
|
||||
<emphasis>logical</emphasis> transaction scope is created for each
|
||||
method that to which the setting is applied. Each such logical
|
||||
method upon which the setting is applied. Each such logical
|
||||
transaction scope can determine rollback-only status individually,
|
||||
with an outer transaction scope being logically independent from the
|
||||
inner transaction scope. Of course, in case of standard
|
||||
|
|
@ -2137,7 +2136,7 @@ TR: REVISED, PLS REVIEW. changed to 'desired'; seems clear that the desired orde
|
|||
the aspect. The simplest way to configure the transaction management
|
||||
aspect is to use the <literal><tx:annotation-driven/></literal>
|
||||
element and specify the <literal>mode</literal> attribute to
|
||||
<literal>asepctj</literal> as described in <xref
|
||||
<literal>aspectj</literal> as described in <xref
|
||||
linkend="transaction-declarative-annotations" />. Because we're focusing
|
||||
here on applications running outside of a Spring container, we'll show
|
||||
you how to do it programmatically.</para>
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@
|
|||
<note>
|
||||
<para>
|
||||
Setting up your application to use JSTL is a common source of error,
|
||||
mainly cause by confusion over the different servlet spec., JSP and JSTL
|
||||
mainly caused by confusion over the different servlet spec., JSP and JSTL
|
||||
version numbers, what they mean and how to declare the taglibs correctly.
|
||||
The article
|
||||
<ulink url="http://www.mularien.com/blog/2008/04/24/how-to-reference-and-use-jstl-in-your-web-application/">
|
||||
|
|
@ -760,7 +760,7 @@ productList.url=/WEB-INF/jsp/productlist.jsp</programlisting>
|
|||
|
||||
<para>A key principle of REST is the use of the Uniform Interface.
|
||||
This means that all resources (URLs) can be manipulated using the same
|
||||
four HTTP methods: GET, PUT, POST, and DELETE. For each methods, the
|
||||
four HTTP methods: GET, PUT, POST, and DELETE. For each method, the
|
||||
HTTP specification defines the exact semantics. For instance, a GET
|
||||
should always be a safe operation, meaning that is has no side
|
||||
effects, and a PUT or DELETE should be idempotent, meaning that you
|
||||
|
|
@ -986,7 +986,7 @@ findOwnersForm.url=/WEB-INF/jsp/findOwners.jsp
|
|||
|
||||
<para><ulink url="http://velocity.apache.org">Velocity</ulink> and <ulink
|
||||
url="http://www.freemarker.org">FreeMarker</ulink> are two templating
|
||||
languages that can both be used as view technologies within Spring MVC
|
||||
languages that can be used as view technologies within Spring MVC
|
||||
applications. The languages are quite similar and serve similar needs and
|
||||
so are considered together in this section. For semantic and syntactic
|
||||
differences between the two languages, see the <ulink
|
||||
|
|
@ -999,8 +999,8 @@ findOwnersForm.url=/WEB-INF/jsp/findOwners.jsp
|
|||
class="libraryfile">velocity-1.x.x.jar</filename> or <filename
|
||||
class="libraryfile">freemarker-2.x.jar</filename> in order to work with
|
||||
Velocity or FreeMarker respectively and <filename
|
||||
class="libraryfile">commons-collections.jar</filename> needs also to be
|
||||
available for Velocity. Typically they are included in the
|
||||
class="libraryfile">commons-collections.jar</filename> is required for
|
||||
Velocity. Typically they are included in the
|
||||
<literal>WEB-INF/lib</literal> folder where they are guaranteed to be
|
||||
found by a Java EE server and added to the classpath for your application.
|
||||
It is of course assumed that you already have the <filename
|
||||
|
|
@ -2593,7 +2593,7 @@ simpleReport.reportDataKey=myBeanData</programlisting>
|
|||
response content as XML. The object to be marshalled can be set explicitly
|
||||
using <classname>MarhsallingView</classname>'s
|
||||
<property>modelKey</property> bean property. Alternatively, the view will
|
||||
iterate over all model properties and marhsall only those types that are
|
||||
iterate over all model properties and marshal only those types that are
|
||||
supported by the <interfacename>Marshaller</interfacename>. For more
|
||||
information on the functionality in the
|
||||
<classname>org.springframework.oxm</classname> package refer to the
|
||||
|
|
|
|||
|
|
@ -627,7 +627,7 @@
|
|||
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
|
||||
ideally do little more than marshall together the correct information
|
||||
ideally do little more than marshal together the correct information
|
||||
and pass it over to a service.</emphasis>
|
||||
</quote>
|
||||
</para>
|
||||
|
|
|
|||
Loading…
Reference in New Issue