[jboss-cvs] JBossAS SVN: r111041 - projects/docs/enterprise/WFK/Spring_Developer_Guide/en-US.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Mon Mar 28 03:08:11 EDT 2011
Author: rebecca_newton
Date: 2011-03-28 03:08:09 -0400 (Mon, 28 Mar 2011)
New Revision: 111041
Modified:
projects/docs/enterprise/WFK/Spring_Developer_Guide/en-US/Getting_Started_Introductory_Example.xml
projects/docs/enterprise/WFK/Spring_Developer_Guide/en-US/Migration_Guide.xml
projects/docs/enterprise/WFK/Spring_Developer_Guide/en-US/Spring_On_JBoss_Best_Practices.xml
projects/docs/enterprise/WFK/Spring_Developer_Guide/en-US/section-Section_A.xml
projects/docs/enterprise/WFK/Spring_Developer_Guide/en-US/section-Section_B.xml
Log:
Line-edits. That is, spelling, grammar, sentence structure, and adding syntax highlighting (unverified), does not currently build with Publican
Modified: projects/docs/enterprise/WFK/Spring_Developer_Guide/en-US/Getting_Started_Introductory_Example.xml
===================================================================
--- projects/docs/enterprise/WFK/Spring_Developer_Guide/en-US/Getting_Started_Introductory_Example.xml 2011-03-27 21:06:36 UTC (rev 111040)
+++ projects/docs/enterprise/WFK/Spring_Developer_Guide/en-US/Getting_Started_Introductory_Example.xml 2011-03-28 07:08:09 UTC (rev 111041)
@@ -7,14 +7,14 @@
<chapter id="Getting_Started_Introductory_Example">
<title>Getting started - an introductory example</title>
- <para>This chapter will provide a quick walkthrough on developing a simple
- Spring MVC web application on JBoss AS, using the JBoss Developer
+ <para>This chapter is a walkthrough of developing a simple
+ Spring MVC web application on JBoss Enterprise Application Platform, using the JBoss Developer
Studio.</para>
<section>
- <title>The tools: prerequisites</title>
+ <title>The Tools: Prerequisites</title>
- <para>During this tutorial, we are using:</para>
+ <para>The following are used during this tutorial:</para>
<itemizedlist>
<listitem>
@@ -22,8 +22,7 @@
</listitem>
<listitem>
- <para>Spring 3.0.5.RELEASE (although the content is not specific to
- this particular version of Spring)</para>
+ <para>Spring 3.0.5.RELEASE</para>
</listitem>
<listitem>
@@ -33,7 +32,7 @@
</listitem>
<listitem>
- <para>JBoss Enterprise Application Platform 5.1.2</para>
+ <para>JBoss Enterprise Application Platform 5.1.1</para>
</listitem>
</itemizedlist>
Modified: projects/docs/enterprise/WFK/Spring_Developer_Guide/en-US/Migration_Guide.xml
===================================================================
--- projects/docs/enterprise/WFK/Spring_Developer_Guide/en-US/Migration_Guide.xml 2011-03-27 21:06:36 UTC (rev 111040)
+++ projects/docs/enterprise/WFK/Spring_Developer_Guide/en-US/Migration_Guide.xml 2011-03-28 07:08:09 UTC (rev 111041)
@@ -14,17 +14,17 @@
Enterprise Web Platform offer a wider variety of middleware services such as
transaction management, messaging or web service integration.</para>
- <para>In this chapter we will illustrate how Spring applications which have
+ <para>This chapter explores how Spring applications that have
been originally developed for servlet containers can be migrated to take
advantage of the JBoss middleware service support and infrastructure. In
order to do so, we will use a few sample applications provided by the Spring
framework.</para>
<section>
- <title>General migration mechanics</title>
+ <title>General Migration Mechanics</title>
<para>Migrating applications from a servlet container to one of the
- enterprise platforms is a fairly simple process, which addresses two
+ enterprise platforms is a simple process, which addresses two
distinct concerns:</para>
<itemizedlist>
@@ -44,31 +44,45 @@
</listitem>
</itemizedlist>
- <para>Except for special situations, migrating applications does not
- involve changes to the Java code, and the Spring bean configuration
- definitions that define the business logic of the application: bean
- wiring, aspect definitions, controllers, etc. The definitions that in
- almost every case are the ones that relate to the infrastructure:
+ <para>Except for rare situations, migrating applications does not
+ involve changes to the Java code, or the Spring bean configuration
+ definitions that define the business logic of the application (bean
+ wiring, aspect definitions, and controllers). The definitions that in
+ almost every case are the ones that relate to the infrastructure are:
datasources, session factories, entity managers and entity manager
- factories, connection factories and transaction managers.</para>
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>factories</para>
+ </listitem>
+ <listitem>
+ <para>
+ connection factories
+ </para>
+ </listitem>
+ <listitem>
+ <para>transaction manager</para>
+ </listitem>
+ </itemizedlist>
<simplesect>
- <title>Avoiding the inclusion of server-provided dependencies</title>
+ <title>Avoiding the Inclusion of Server-Provided Dependencies</title>
<para>The JBoss Enterprise platforms already provide a number of
dependencies that are required by applications. This is unlike servlet
containers, where applications need to package a significant number of
libraries in order to provide access to certain Java EE 5 technologies.
- So, one of the first things that needs to be considered in the migration
+ One of the first things that needs to be considered in the migration
process is changing the deployable build by removing the libraries which
are already provided by the application server. It is not just an
improvement which reduces the size of the final build, but also a
- requirement, since the inclusion of those libraries will, most likely,
- result in classloading errors. For an analogy, this is in all respects
+ requirement, since the inclusion of those libraries will
+ result in classloading errors. <!--For an analogy, this is in all respects
similar to what applications already do with respect to the Servlet API
- when running in a</para>
+ when running in a --></para>
- <para>Some examples of libraries provided by JBoss AS which do not need
+ <para>Some examples of libraries provided by JBoss Enterprise Application
+ Platform which do not need
to be included in the application are:</para>
<itemizedlist>
@@ -85,8 +99,9 @@
</listitem>
</itemizedlist>
- <para>Please consult the list of components included in JBoss EAP for a
- complete list. Of course, the components mentioned above may be required
+ <para>Please consult the list of components included in JBoss Enterprise
+ Application Platform for a complete list. Of course, the
+ components mentioned above may be required
as compile-time dependencies, so please make sure that they are included
in the project, but not packaged in the final build. In Maven builds,
this can be achieved by setting the scope to 'provided' and in JBDS by
@@ -94,8 +109,9 @@
have their own respective mechanisms of achieving the same goal.</para>
<para>On the other hand, components and frameworks that are not part of
- the Java EE 5 implementation but are certified for use with JBoss AS 5
- need to be included in your application. Such components are:</para>
+ the Java EE 5 implementation but are certified for use with JBoss Enterprise
+ Application Platform 5 need to be included in your application.
+ These components are:</para>
<itemizedlist>
<listitem>
@@ -118,13 +134,13 @@
</simplesect>
<simplesect>
- <title>Migrating datasource definitions</title>
+ <title>Migrating Datasource Definitions</title>
- <para>Almost all servlet containers support the usage of JNDI-bound
+ <para>Almost all servlet containers support the use of JNDI-bound
resources, and binding Datasources in JNDI allows for managing
- connectivity parameters such as URLs, credentials and pool sizes
- independently from the application code. However, it is quite typical
- for Spring applications to rely on independent connection pool bean
+ connectivity parameters such as URLs, credentials, and pool sizes
+ independently from the application code. However, Spring applications often
+ rely on independent connection pool bean
definitions, such as the ones used by commons-dbcp or c3po (see example
<xref linkend="dbcp-ref" />).</para>
@@ -132,19 +148,20 @@
<title id="dbcp-def">Example commons-dbcp DataSource definition in a
servlet container</title>
- <programlisting><bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
+ <programlisting language="XML"><bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
<property name="driverClassName" value="org.postgresql.Driver" />
<property name="url" value="jdbc:postgresql://exampleHost/exampleDatabase" />
<property name="username" value="user" />
<property name="password" value="password" />
</bean></programlisting>
- <para>JBoss provides simple and efficient way of deploying and
+ <para>JBoss provides an efficient way of deploying and
maintaining managed datasources (see section <xref
- linkend="managed_ds" /> for more details and the JBoss EAP 5
- administration guide on how to deploy the,) which are JNDI-accessible.
+ linkend="managed_ds" /> for more details and the <citetitle>JBoss Enterprise
+ Application Platform Administration and Configuration Guide</citetitle>
+ for how to deploy them,) which are JNDI-accessible.
In order to replace the above defined datasource with a managed,
- JNDI-accessible datasource, you need to replace the bean definition
+ JNDI-accessible datasource, replace the bean definition
with a JNDI object reference as in <xref
linkend="jboss-managed-ds" />.</para>
</example>
@@ -153,10 +170,10 @@
<title id="jboss-managed-ds">Using a JBoss managed datasource in
Spring</title>
- <programlisting><jee:jndi-lookup id="dataSource" jndi-name="java:/ExampleDsJndiName" expected-type="javax.sql.DataSource"/></programlisting>
+ <programlisting language="XML"><jee:jndi-lookup id="dataSource" jndi-name="java:/ExampleDsJndiName" expected-type="javax.sql.DataSource"/></programlisting>
<para>Preserving the bean id is important for the case when the bean
- is injected by name, whereas indicating the expected type specifically
+ is injected by name. Indicating the expected type specifically
is important for @Autowired scenarios.</para>
</example>
</simplesect>
@@ -164,11 +181,12 @@
<simplesect>
<title>Migrating Hibernate SessionFactories to JTA</title>
- <para>Applications running on the JBoss enterprise platforms are
- encouraged to use JTA for transaction management. In such cases, the
+ <para> User running applications on the JBoss Enterprise
+ Application Platform are encouraged to use JTA for transaction
+ management. In such cases, the
infrastructure changes consist of altering the session factory
definition to allow for JTA-backed session context and replacing the
- local Spring-based transction manager with a
+ local Spring-based transaction manager with a
HibernateTransactionManager.</para>
<para>Listing <xref linkend="hibernate_sf" /> contains typical bean
@@ -180,7 +198,7 @@
<title>SessionFactory and transaction manager definitions in a servlet
environment</title>
- <programlisting><bean id="sessionFactory" class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">
+ <programlisting language="XML"><bean id="sessionFactory" class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">
<property name="dataSource" ref="dataSource"/>
<property name="mappingLocations" value="classpath:**/*.hbm.xml"/>
<property name="hibernateProperties">
@@ -203,7 +221,7 @@
<example>
<title>JTA-based SessionFactory and transaction manager</title>
- <programlisting><bean id="sessionFactory" class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">
+ <programlisting language="XML"><bean id="sessionFactory" class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">
<property name="dataSource" ref="dataSource"/>
<property name="mappingLocations" value="classpath:**/*.hbm.xml"/>
<property name="hibernateProperties">
@@ -219,32 +237,33 @@
<tx:jta-transaction-manager id="transactionManager"/>
</programlisting>
-
- <para>Please note the the definitions of the 'sessionFactory' bean is
+ <note>
+ <para>The definitions of the 'sessionFactory' bean is
virtually unchanged - the only difference is the addition of the
properties required for setting up the JTA-based context management
and the transaction manager change.</para>
+ </note>
</example>
</simplesect>
<simplesect>
- <title>Migrating JPA-based applications</title>
+ <title>Migrating JPA-based Applications</title>
- <para>The most important aspect that needs to be taken into account in
- the case of JPA is that full fledged Java EE 5 environments have certain
+ <para>The most important aspect in
+ the case of JPA is that fully-fledged Java EE 5 environments have certain
restrictions regarding what is deployable by the container and what
- isn't. More specifically, a persistence unit definition contained in a
- META-INF/persistence.xml file will be automatically deployed by the
- container, cannot declare a RESOURCE_LOCAL transaction type and must
+ is not. Specifically, a persistence unit definition contained in a
+ <filename>META-INF/persistence.xml</filename> file will be automatically deployed by the
+ container, cannot declare a RESOURCE_LOCAL transaction type, and must
include a JTA datasource reference.</para>
- <para>On the other hand, it is quite common for applications that are
+ <para>However, it is quite common for applications that are
deployed in a servlet container to use RESOURCE_LOCAL transactions as
- shown in example <xref linkend="jpa-servlet-container" />, or even not
+ shown in example <xref linkend="jpa-servlet-container" />. It may also not
specify any transaction type (which is equivalent to setting a JTA
transaction type, but is ignored when the persistence unit is
initialized by Spring and a resource-local model will be used instead).
- As well, it is atypical for servlet-container based applications to use
+ It is also atypical for servlet-container based applications to use
JTA datasources, as seen in the same example <xref
linkend="jpa-servlet-container" />.</para>
@@ -252,7 +271,7 @@
<title>A sample persistence unit definition for a servlet-container
based application</title>
- <programlisting><persistence-unit name="examplePU" transaction-type="RESOURCE_LOCAL">
+ <programlisting language="XML"><persistence-unit name="examplePU" transaction-type="RESOURCE_LOCAL">
<provider>org.hibernate.ejb.HibernatePersistence</provider>
<properties>
<property name="hibernate.dialect" value="org.hibernate.dialect.PostgreSQLDialect"/>
@@ -263,10 +282,10 @@
</example>
<para>A servlet container will not deploy a persistence unit
- automatically, as a Java EE 5 application server would, therefore Spring
+ automatically, as a Java EE 5 application server would. Therefore Spring
applications using JPA will rely on Spring to create the persistence
unit by using one of its JPA support factory beans. Furthermore, while
- in a Java EE 5 application server enrollment in JTA transactions is a
+ in a Java EE 5 application, server enrollment in JTA transactions is a
requirement, Spring applications running outside Java EE have to set up
a resource-local transaction manager as described in example <xref
linkend="???" />.</para>
@@ -275,7 +294,7 @@
<title>JPA EntityManagerFactory and transaction setup in a
servlet-container based application</title>
- <programlisting><bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean"
+ <programlisting language="XML"><bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean"
p:dataSource-ref="dataSource">
<property name="jpaVendorAdapter">
<bean class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter"
@@ -292,52 +311,52 @@
<para>This persistence unit definition, as laid out above, is not
compatible with the requirements of Java EE 5 for application containers
and will lead to the a deployment failure if found in the typical
- META-INF/persistence.xml location.</para>
+ <filename>META-INF/persistence.xml</filename> location.</para>
- <para>So, there are a couple of solution for turning this into a an
- application that can be deployed in JBoss:</para>
+ <para>
+ To solve this problem and turn it into an application that can be deployed in JBoss:
+ </para>
<itemizedlist>
<listitem>
- <para>renaming the persistence unit definition file;</para>
+ <para>rename the persistence unit definition file;</para>
</listitem>
<listitem>
- <para>leaving persistence-unit deployment to JBoss and using JNDI
+ <para>leave persistence-unit deployment to JBoss and using JNDI
lookup for retrieving entity managers and entity manager
- factories;</para>
+ factories.</para>
</listitem>
</itemizedlist>
<para>When renaming the persistence unit, the alternate location can be
provided as a property to the LocalContainerEntityManagerFactoryBean as
described in example <xref linkend="jpa-pu-with-alternate-pxml" />. For
- details using the LocalContainerEntityManagerFactoryBean in JBoss and
- its implications please refer to the previous chapter.</para>
+ details about using the LocalContainerEntityManagerFactoryBean in JBoss and
+ its implications, please refer to the previous chapter.</para>
<example>
<title>LocalContainerEntityManagerFactoryBean with alternate
persistence.xml location</title>
- <programlisting id="jpa-pu-with-alternate-pxml"><bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
+ <programlisting id="jpa-pu-with-alternate-pxml" language="XML"><bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
<property name="persistenceXmlLocation" value="classpath*:META-INF/jpa-persistence.xml"/>
<!-- other properties (ommitted) -->
</bean></programlisting>
- <para>A more effective approach is converting the persistence.xml
+ <para>A more effective approach is converting the <filename>persistence.xml</filename>
definition to a JTA-based model and using JNDI lookup for retrieving
the entity manager. For this, you must convert the persistence unit
definition as in the following example (please note that it is not
necessary to provide values for both 'jboss.entity.manager.jndi.name'
- and 'jboss.entity.manager.factory.jndi.name', but at least the entity
- manager or the entity manager factory</para>
+ and 'jboss.entity.manager.factory.jndi.name', but one must be specified)</para>
</example>
<example>
<title>Changing the persistence.xml definition to be Java EE
5-compatible</title>
- <programlisting><persistence-unit name="examplePU">
+ <programlisting language="XML"><persistence-unit name="examplePU">
<jta-data-source>java:/ExampleDsJndiName</jta-data-source>
<properties>
<property name="hibernate.show_sql" value="true"/>
@@ -346,33 +365,33 @@
</properties>
</persistence-unit></programlisting>
- <para>Now, the EntityManagerFactory and or a JTA-synchronized
+ <para>The EntityManagerFactory or a JTA-synchronized
EntityManager can be retrieved from JNDI as follows:<example>
<title>EntityManager retrieved by JNDI lookup and JTA transaction
manager (works with @Autowired)</title>
- <programlisting><jee:jndi-lookup id="entityManager" jndi-name="java:/example/EntityManager" expected-type="javax.persistence.EntityManager"/>
+ <programlisting language="XML"><jee:jndi-lookup id="entityManager" jndi-name="java:/example/EntityManager" expected-type="javax.persistence.EntityManager"/>
<tx:jta-transaction-manager/></programlisting>
<para>If the original application relied on Spring to inject the
EntityManager using the @PersistenceContext annotation into
- services and DAOs, then going the EntityManager route will require
+ services and DAOs, using the EntityManager will require
changing the annotation to @Autowired (as the bean is an
- EntityManager). In such cases, it may be preferrable to look up
+ EntityManager). In such cases, it may be better to look up
for the EntityManagerFactory instead, and leave Spring to create
the EntityManager.</para>
<para>A particular concern when migrating JPA-based application is
the choice of a JPA provider. While servlet-container-based
applications have to include a JPA implementation and specify the
- nature of the provider explicitely, JBoss EAP uses Hibernate as a
- JPA provider. <example>
+ nature of the provider explicitly, JBoss Enterprise Application
+ Platform uses Hibernate as a JPA provider. <example>
<title>EntityManagerFactory retrieved by JNDI lookup and JTA
transaction manager (works with @PersistenceContext)</title>
- <programlisting><jee:jndi-lookup id="entityManager" jndi-name="java:/example/EntityManager" expected-type="javax.persistence.EntityManager"/>
+ <programlisting language="XML"><jee:jndi-lookup id="entityManager" jndi-name="java:/example/EntityManager" expected-type="javax.persistence.EntityManager"/>
<tx:jta-transaction-manager/></programlisting>
@@ -391,7 +410,7 @@
implementation and specify the nature of the provider
explicitely, JBoss EAP uses Hibernate as the unique JPA
provider. In such cases, using an application-server deployed
- persistence unit will greatly simplify the process.</para>
+ persistence unit simplifies the process.</para>
</example></para>
</example></para>
</example>
@@ -406,26 +425,26 @@
https://src.springframework.org/svn/spring-samples/petclinic/trunk/.</para>
<para>The example provides a number of alternative data access
- implementations that can be used alternatively by changing the web.xml
- file. We will show the migration strategies in each and every case, noting
+ implementations that can be used alternatively by changing the <filename>web.xml</filename>
+ file. This shows the migration strategies in each case, noting
that only one of these strategies is used at a time.</para>
<simplesect>
- <title>Preliminary changes</title>
+ <title>Preliminary Changes</title>
- <para>Before starting the actual migration process, we will make a few
- adjustments to the POM file, in order to retrieve dependencies from
- Maven Central and/or the JBoss repository. The changes consist of
+ <para>Before starting the actual migration process, a few
+ adjustments to the POM file will be made, in order to retrieve dependencies from
+ Maven Central or the JBoss repository. The changes consist of
renaming artifacts and do not affect the structure of the project, in
the sense that the final build will be equivalent with the original in
terms of included dependencies, except that it will built with
components retrieved from Maven Central and the JBoss repository. The
- changed pom can be found in Appendix A, and you can just copy its
- contents over the original pom.xml.</para>
+ changed POM can be found in Appendix A, and its content can be copied
+ over to the original <filename>pom.xml</filename>.</para>
</simplesect>
<simplesect>
- <title>Adjusting dependencies</title>
+ <title>Adjusting Dependencies</title>
<para>One of the first things that we need to focus on is adjusting
dependency scopes. They will need to change as follows:</para>
@@ -433,7 +452,7 @@
<itemizedlist>
<listitem>
<para>commons-dbcp:commons-dbcp, commons-pool:commons:pool and
- org.hsqldb:hsqldb become test-scoped dependencies - a pooled
+ org.hsqldb:hsqldb become test-scoped dependencies. A pooled
datasource will be retrieved from JNDI at runtime, so they are
needed only for running tests;</para>
</listitem>
@@ -442,10 +461,10 @@
<para>javax.persistence:persistence-api,
org.hibernate:hibernate-core, org.hibernate:hibernate-entitymanager,
org.hibernate:hibernate-annotations become provided-scope
- dependencies - JBoss enterprise platforms include a JPA
+ dependencies. JBoss enterprise platforms include a JPA
implementation, so there is no need for the application to include
- these libraries in the WAR, however they are needed for compiling
- the application, however, they are needed for compiling and running
+ these libraries in the WAR, but they are needed for compiling
+ the application. They are also needed for compiling and running
unit tests;</para>
</listitem>
@@ -456,8 +475,8 @@
<listitem>
<para>toplink.essentials:toplink-essentials and
- org.apache.openjpa:openjpa will be removed from the dependency set -
- since we will use Hibernate exclusively as a JPA provider.</para>
+ org.apache.openjpa:openjpa will be removed from the dependency set,
+ since Hibernate will be used exclusively as a JPA provider.</para>
</listitem>
</itemizedlist>
Modified: projects/docs/enterprise/WFK/Spring_Developer_Guide/en-US/Spring_On_JBoss_Best_Practices.xml
===================================================================
--- projects/docs/enterprise/WFK/Spring_Developer_Guide/en-US/Spring_On_JBoss_Best_Practices.xml 2011-03-27 21:06:36 UTC (rev 111040)
+++ projects/docs/enterprise/WFK/Spring_Developer_Guide/en-US/Spring_On_JBoss_Best_Practices.xml 2011-03-28 07:08:09 UTC (rev 111041)
@@ -5,28 +5,28 @@
%BOOK_ENTITIES;
]>
<chapter id="Spring_On_JBoss_Best_Practices">
- <title>Best practices and integration guidelines</title>
+ <title>Best Practices and Integration Guidelines</title>
<para>The Spring Framework is a flexible environment for developing
- enterprise applications. .This means that the developer has the benefit of
- being able to choose between a number of alternatives when it comes to
- accessing middleware services.</para>
+ enterprise applications. This means that the developer can choose
+ between a number of alternatives when it comes to accessing middleware
+ services.</para>
- <para>JBoss is a feature-rich application server, that provides a complex
- and performant set of middleware services. Spring developers can take
+ <para>JBoss is a feature-rich application server, which provides a complex
+ set of middleware services. Spring developers can take
advantage of those services by opting to use the dedicated Java EE
integration features of Spring.</para>
<section>
- <title>Setting up data access</title>
+ <title>Setting Up Data Access</title>
<para>Spring applications can either deploy their own data access
infrastructure, or rely on a managed infrastructure provided by the
application server. The recommended practice for JBoss is to use the
- server-provided infrastructure. In general we recommend using a managed
+ server-provided infrastructure. In general, use a managed
infrastructure using JTA transaction management.</para>
- <para>The following subsections will detail the configuration strategy
+ <para>The following subsections detail the configuration strategy
for:</para>
<itemizedlist>
@@ -48,23 +48,23 @@
</itemizedlist>
<section id="managed_ds">
- <title>Database access through managed datasources</title>
+ <title>Database Access Through Managed Datasources</title>
- <para>On JBoss we recommend using managed datasources, which are
- accessible via JNDI, and can be deployed through a simple configuration
+ <para>On JBoss it is recommended that managed datasources are used.
+ These are accessible via JNDI, and can be deployed through a simple configuration
file.</para>
- <para>The definition for such a datasource would be included in a file
- whose name ends in -ds.xml (e.g. sportsclub-ds.xml) and can either
- copied in the deploy directory of the target JBoss AS configuration for
- deployment at startup, or it can be included in the META-INF directory
+ <para>The definition for such a datasource is included in a file
+ that ends in -ds.xml (for example, <filename>sportsclub-ds.xml</filename>) and can either
+ be copied in the deploy directory of the target JBoss AS configuration for
+ deployment at startup, or be included in the META-INF directory
of the application for being deployed together with the
application.</para>
<example>
- <title>Managed datasource configuration</title>
+ <title>Managed Datasource Configuration</title>
- <programlisting language="xml"><datasources>
+ <programlisting language="XML"><datasources>
<local-tx-datasource>
<jndi-name>ExampleDsJndiName</jndi-name>
@@ -75,69 +75,69 @@
</datasources></programlisting>
</example>
- <para>The datasource will be bound in JNDI at java:/ExampleDsJndiName.
+ <para>The datasource is bound in JNDI at java:/ExampleDsJndiName.
It can be referenced from a Spring ApplicationContext by using the
following definition:</para>
<example>
- <title>Defining a managed datasource Spring bean</title>
+ <title>Defining a Managed Datasource Spring Bean</title>
<programlisting lang="xml"><jee:jndi-lookup id="dataSource" jndi-name="java:/ExampleDsJndiName" expected-type="javax.sql.DataSource"/></programlisting>
</example>
- <para>Such a datasource bean can be injected in any regular Spring bean
- (e.g. a JBDS DAO).</para>
+ <para>A datasource bean can be injected in any regular Spring bean
+ (for example, a JBDS DAO).</para>
</section>
<section>
- <title>Defining and using a Hibernate SessionFactory</title>
+ <title>Defining and Using a Hibernate SessionFactory</title>
<para>Applications that use Hibernate directly (as opposed to JPA)
should take advantage of the fact that Hibernate is already included in
the application server. Therefore, applications do not need to include a
Hibernate distribution.</para>
- <para>Spring applications can use one of the Spring's
+ <para>Spring applications can use one of Spring's
SessionFactory-instantiating FactoryBeans, and a managed datasource (see
previous section for details).</para>
<example>
<title>SessionFactory bean definition</title>
- <para><programlisting lang="xml"><bean id="sessionFactory" class="org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean">
+ <para><programlisting language="XML"><bean id="sessionFactory" class="org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean">
<property name="dataSource" ref="dataSource"/>
...
</bean></programlisting></para>
</example>
- <para>We recommend JTA transaction management and Hibernate-JTA session
- management integration by setting up the following properties:</para>
+ <para>JTA transaction management and Hibernate-JTA session
+ management integration is recommended by setting up the following properties:</para>
<example>
<title>JTA session management setup properties</title>
- <programlisting language="xml">hibernate.current_session_context_class=jta
+ <programlisting language="XML">hibernate.current_session_context_class=jta
hibernate.transaction.manager_lookup_class=org.hibernate.transaction.JBossTransactionManagerLookup
hibernate.transaction.factory_class=org.hibernate.transaction.JTATransactionFactory</programlisting>
</example>
- <para>Once such a SessionFactory has been defined, it can be injected in
+ <para>Once a SessionFactory has been defined, it can be injected in
component classes such as DAOs and used directly as in the following
- example.</para>
+ example:</para>
- <example>
+<!-- <example>
<title>Hibernate-based DAO: a SessionFactory is injected directly in
- the bean</title>
+ the bean</title> -->
- <para><programlisting language="java">public class HibernateAccountDao {
+ <programlisting language="java">public class HibernateAccountDao {
@Autowired SessionFactory sessionFactory;
public List<Account> getAllAccounts() {
return sessionFactory.getCurrentSession().getCriteria(Account.class).list();
}
...
-}</programlisting></para>
- </example>
+}</programlisting>
+ <!-- </example> -->
<para>A comprehensive example of using Hibernate-driven data access in
Spring-based applications can be found in the Sportsclub demo
@@ -148,7 +148,7 @@
<title>Using JPA</title>
<section>
- <title>PersistenceUnit deployed by the container</title>
+ <title>PersistenceUnit Deployed by the Container</title>
<para>Spring applications can retrieve the persistence units deployed
by the container by looking them up in JNDI. In order to be able to
@@ -159,7 +159,7 @@
<example>
<title>Persistence unit definition</title>
- <programlisting language="xml"><persistence xmlns="http://java.sun.com/xml/ns/persistence" version="1.0">
+ <programlisting language="XML"><persistence xmlns="http://java.sun.com/xml/ns/persistence" version="1.0">
<persistence-unit name="sportsclubPU">
<jta-data-source>java:/ExampleDsJndiName</jta-data-source>
<properties>
@@ -172,8 +172,8 @@
</example>
<para>Spring applications can use either container-managed entity
- managers or, if necessary, application-managed entity managers (case
- in which they will be provided with the corresponding entity manager
+ managers or, if necessary, application-managed entity managers (in this case,
+ they will be provided with the corresponding entity manager
factories). A container-managed entity manager can be accessed as a
Spring Bean as follows:</para>
@@ -181,17 +181,17 @@
<title>Spring bean representing a container-managed entity
manager</title>
- <programlisting language="xml"><jee:jndi-lookup id="entityManager" jndi-name="java:/example/em"/></programlisting>
+ <programlisting language="XML"><jee:jndi-lookup id="entityManager" jndi-name="java:/example/em"/></programlisting>
</example>
<para>Such an EntityManager can be used directly if injected in
- component classes such as DAOs. When doing so, the</para>
+ component classes such as DAOs. <!-- When doing so, the COMMENTED OUT UNTIL THE SENTENCE IS COMPLETE--></para>
<example>
<title>Hibernate-based DAO: a SessionFactory is injected directly in
the bean</title>
- <para><programlisting language="xml">public class HibernateAccountDao {
+ <para><programlisting language="XML">public class HibernateAccountDao {
@Autowired EntityManager entityManager;
public List<Account> getAllAccounts() {
@@ -202,25 +202,23 @@
</example>
<para>As an alternative, an EntityManagerFactory can also be used
- directly, either relying on Spring's ability of performing
+ directly, either relying on Spring's ability to perform
@PersistenceContext injection with a transactional EntityManager or
when the scenario requires an application-managed entityManager. Here
is an example of acquiring the entityManagerFactory from JNDI.</para>
<example>
- <title>Spring bean representing an entity manager factory</title>
+ <title>Spring Bean Representing an Entity Manager Factory</title>
<programlisting language="xml"><jee:jndi-lookup id="entityManagerFactory" jndi-name="java:/example/emf"/></programlisting>
</example>
- <para>In general, for implementing transaction-aware components (for
- example a service that delegates to multiple DAOs which have to be
- enrolled in the same transaction), it is not typical to access
- EntityManagerFactories directly, even if Spring supports injection
- into fields annotated with @PersistenceContext if an
- EntityManagerFactory provided. Rather, components should access the
+ <para>In general, for implementing transaction-aware components, it is not typical to access EntityManagerFactories directly (for example a service that delegates to multiple DAOs which have to be
+ enrolled in the same transaction). This is true even if Spring supports injection
+ into fields annotated with @PersistenceContext when an
+ EntityManagerFactory is provided. Rather, components should access the
JNDI-bound EntityManager, as it is JTA-synchronized and will be shared
- with non-Spring components that use JPA as well (e.g. EJBs).</para>
+ with non-Spring components that use JPA as well (for example EJBs).</para>
<para>A comprehensive example of using JPA-driven data access in
Spring-based applications can be found in the Sportsclub demo
@@ -237,41 +235,41 @@
read-only as in example</para>
<example id="transactional-method-read-only">
- <title>A Spring method declaring a read-only transaction</title>
+ <title>A Spring Method Declaring a Read-Only Transaction</title>
- <programlisting language="java">@Transaction(readOnly = true)
+ <programlisting language="Java">@Transaction(readOnly = true)
public List<Account> getAllAccounts() {
return entityManager.createQuery("SELECT a FROM Account").getResultList();
}</programlisting>
</example>
- <para>A common misconception is that the readOnly flag will prevent
- the transaction from committing. What it actually means is that the
+ <para>A common misconception is that the Read-Only flag will prevent
+ the transaction from committing. In fact, it means that the
application is not expected to change the entities retrieved in the
persistence context, therefore it can be flushed at the end of the
- transaction. As such, the readOnly flag is a hint to Spring, which
+ transaction. As such, the Read-Only flag is a hint to Spring, which
will attempt to prevent the persistence context (and in the case of
using Hibernate as a persistence provider, underlying SessionFactory)
from being automatically flushed upon commit. The expected benefit of
this operation mode is a performance increase, as the persistence
context will be simply discarded when the transaction ends. It should
be noted that support for this mode is not obligatory in Spring, and
- applications are not expected to rely on this behaviour at all time
- (cf. Spring reference documentation for details).</para>
+ applications are not expected to rely on this behaviour at all time.
+ <!-- (cf. Spring reference documentation for details).--></para>
<para>This behaviour is supported by Spring-defined
- EntityManagerFactories for certain JPA providers (Hibernate which is
- the JPA provider for JBoss being one of them), but not when the
+ EntityManagerFactories for certain JPA providers (the JPA
+ provider for JBoss, Hibernate, is one of them), but not when the
EntityManager or EntityManagerFactory is provided from JNDI.
Therefore, in any circumstance when the application needs support for
- readOnly persistence contexts, a JTA-integrated
+ Read-Only persistence contexts, a JTA-integrated
LocalContainerEntityManagerFactoryBean should be used instead. An
- example of such a bean definition for JBoss is provided here:</para>
+ example of a bean definition for JBoss is provided here:</para>
<example>
<title>A Spring-defined JTA-based entity manager factory</title>
- <para><programlisting><bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
+ <para><programlisting language="XML"><bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
<property name="jpaVendorAdapter">
<bean class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter"/>
</property>
@@ -284,9 +282,9 @@
</property>
</bean></programlisting></para>
- <para>The above definition relies upon a META-INF/persistence.xml
- file being provided in the deployment. However, in such a case it
- may be worth considering whether it is necessary to have a
+ <para>The above definition relies upon a <filename>META-INF/persistence.xml</filename>
+ file being provided in the deployment. However, if it is not present,
+ it may not be necessary to have a
container-deployed persistence unit as well, since the Spring
application will not use it. If that is not the case, you can use
another location as shown in example <xref
@@ -296,7 +294,7 @@
<example>
<title>Using an alternative location for persistence.xml</title>
- <para><programlisting lang="XML" language="xml"><bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
+ <para><programlisting language="XML"><bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
<property name="persistenceXmlLocation" value="classpath*:META-INF/persistence-booking.xml"/>
<!-- other properties (ommitted) -->
</bean></programlisting></para>
@@ -306,19 +304,19 @@
the WEB-INF/classes location will not be scanned for persistent
entities, even if the persistence unit definition file is located in
WEB-INF/classes/META-INF. This happens irrespective of whether the
- file is named persistence.xml or otherwise. In such cases, the list of
- entities must be provided explicitely through one of the following
- methods:</para>
+ file is named <filename>persistence.xml</filename>.
+ In this case, the list of entities must be provided explicitly
+ through one of the following methods:</para>
<itemizedlist>
<listitem>
- <para>By enumerating the persistent classes in persistence.xml (or
+ <para>By enumerating the persistent classes in <filename>persistence.xml</filename> (or
however the persistence unit configuration file is named);</para>
</listitem>
<listitem>
<para>By packaging the entities in a jar file and provide a
- <jar-file/> configuration entry in persistence.xml;</para>
+ <jar-file/> configuration entry in <filename>persistence.xml</filename>;</para>
</listitem>
<listitem>
@@ -330,13 +328,13 @@
of JPA. The third solution, however, is Spring-specific and involves
implementing a PersistenceUnitPostprocessor class that will add the
persistent classes directly to the PersistenceUnitInfo object, as in
- the following example.</para>
+ the following example:</para>
<example>
<title>Example of a PersistenceUnitPostProcessor implementation that
adds all classes annotated with @Entity</title>
- <programlisting language="java">package org.springframework.webflow.samples.booking;
+ <programlisting language="Java">package org.springframework.webflow.samples.booking;
import java.io.IOException;
@@ -384,7 +382,7 @@
<title>Adding the PersistenceUnitPostProcessor to the context
definition</title>
- <para><programlisting language="xml"><bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
+ <para><programlisting language="XML"><bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
<!-- other properties -->
<property name="persistenceUnitPostProcessors">
<list>
@@ -396,7 +394,7 @@
</section>
<section>
- <title>@PersistenceContext and @PersistenceUnit injection</title>
+ <title>@PersistenceContext and @PersistenceUnit Injection</title>
<para>Spring does @PersistenceContext injection into Spring components
on its own. In order to do so, applications need to be have access to
@@ -404,27 +402,27 @@
JNDI). </para>
<para>In certain cases, however, the presence of
- @PersistenceContext/@PersistenceUnit annotations on Spring beans may
- cause deployment errors, when the persistence.xml file has been
+ @PersistenceContext/@PersistenceUnit annotations in Spring beans may
+ cause deployment errors, when the <filename>persistence.xml</filename> file has been
renamed (for example in order to use a Spring-based
- EntityManagerFactory as shown previously). In a Java EE 5 environment,
+ EntityManagerFactory). In a Java EE 5 environment,
the @PersistenceContext and @PersistenceUnit annotations are used for
supporting the container-driven injection of container-managed
persistence contexts and persistence units, respectively. During
- deployment, JBoss EAP will scan the deployment classes and will
- validate that, if such annotations are found, the corresponding
- managed persistence units exist as well, which is not the case if the
- persistence.xml file has been renamed.</para>
+ deployment, JBoss Enterprise Application Platform scans the
+ deployment classes. It will validate that, if such annotations are found, the corresponding
+ managed persistence units exist as well. This is not the case if the
+ <filename>persistence.xml</filename> file has been renamed.</para>
- <para>This situation can be solved simply, either by disabling the
- scanning of deployment classes or by using @Autowire injection.
+ <para>This situation can be solved either by disabling the
+ scanning of deployment classes, or by using the @Autowire injection.
</para>
- <para>In the case of Spring-based deployments the injection of
+ <para>In the case of Spring-based deployments, the injection of
components and resources is done by Spring and not by JBoss, so in
most cases it is not necessary for JBoss to perform the scanning at
all. For web applications conforming to the Servlet 2.5 specification
- this can be simply set up through the metadata-complete attribute
+ this can be set up through the metadata-complete attribute
(applications that use the Servlet 2.4 standard do not exhibit this
problem at all, since annotation-based injection is not supported by
the container) .</para>
@@ -433,7 +431,7 @@
<title>The metadata-complete flag can be used to disable class
scanning by JBoss</title>
- <programlisting><web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee"
+ <programlisting language="XML"><web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
metadata-complete="true"></programlisting>
@@ -444,8 +442,8 @@
of replacing the annotation, but @PersistenceContext requires an
extra step. </para>
- <para>f you are using a container-deployed EntityManagerFactory,
- then you can simply register bind the EntityManager in JNDI, as
+ <para>If you are using a container-deployed EntityManagerFactory,
+ you can register bind the EntityManager in JNDI, as
explained in the previous subsection, and use a JNDI lookup bean to
retrieve it.</para>
@@ -459,7 +457,7 @@
<title>Using a SharedEntityManager bean to create an injectable
transaction-aware EntityManager</title>
- <programlisting><bean id="entityManagerWrapper" class="org.springframework.orm.jpa.support.SharedEntityManagerBean">
+ <programlisting language="XML"><bean id="entityManagerWrapper" class="org.springframework.orm.jpa.support.SharedEntityManagerBean">
<property name="entityManagerFactory" ref="entityManagerFactory"/>
</bean></programlisting>
</example>
@@ -468,7 +466,7 @@
</section>
<section id="messaging_integration">
- <title>Messaging (JMS) integration</title>
+ <title>Messaging (JMS) Integration</title>
<para>Spring applications have two distinct mechanisms of integrating with
JMS. One is by using the JmsTemplate which simplifies the usage of the JMS
@@ -476,23 +474,23 @@
implementing message-driven POJOs.</para>
<para>The best practice in JBoss is to use the JmsTemplate for sending
- messages, but not for receiving them, as the message-driven/event-driven
+ messages, but not for receiving them. <!--This is because the message-driven/event-driven
paradigm is a superior approach both as a programming style and
performance-wise than polling/blocking via
- JmsTemplate.receiveMessage().</para>
+ JmsTemplate.receiveMessage(). --></para>
<para>Spring applications can implement message-driven POJOs by wiring
MessageListener beans (or POJOs via a MessageListenerAdapter) into a
MessageListenerContainer.</para>
- <para>An typical of a message-driven POJO can be seen in example <xref
+ <para>A typical message-driven POJO can be seen in example <xref
linkend="listing-message-driven-pojo" />.</para>
<example id="listing-message-driven-pojo">
<title>A message-driven POJO is a simple Java class with a
single-argument method</title>
- <programlisting>
+ <programlisting language="Java">
public class MessageDrivenPojo
{
@Autowire PaymentProcessor paymentProcessor;
@@ -505,19 +503,19 @@
</programlisting>
</example>
- <para>Spring provides two dfferent types of MessageListenerContainers:
- 'native' JMS and JCA-based. On JBoss AS we recommend using the JCA
- MessageListenerContainer, due to the better integration with the
- application server in what concerns message delivery and session,
+ <para>Spring provides two dfferent types of MessageListenerContainers;
+ 'native' JMS, and JCA-based. Using the JCA MessageListenerContainer
+ on JBoss Enterprise Application Platform, due to better integration with the
+ application server for message delivery and session,
connection, and message consumer management. In order to minimize the
- amount of proprietary code, you can use Snowdrop's namespace support for
- JMS/JCA integration (see Snowdrop documentation for details).</para>
+ amount of proprietary code, Snowdrop's namespace support for
+ JMS/JCA integration can be used <!--(see Snowdrop documentation for details) -->.</para>
<example>
<title>Using the JCA message listener containers and namespace support
in JBoss</title>
- <para><programlisting language="xml"> <jms:jca-listener-container resource-adapter="resourceAdapter" acknowledge="auto"
+ <para><programlisting language="XML"> <jms:jca-listener-container resource-adapter="resourceAdapter" acknowledge="auto"
activation-spec-factory="activationSpecFactory">
<jms:listener destination="/someDestination" ref="messageDrivenPojo"
method="pojoHandlerMethod"/>
@@ -531,10 +529,9 @@
<bean id="messageDrivenPojo" class="example.MessageDrivenPojo"/></programlisting></para>
</example>
- <para>Whenever a message arrives to the destination, it will be converted
- to the argument type of the method <emphasis>pojoHandlerMethod</emphasis>
- of the messageDrivenPojo bean which will be invoked by the container. Any
- regular bean can be a message-driven POJO, the only restriction being that
+ <para>When a message arrives, the container will invoke the messageDrivenPojo bean.
+ The message will then be converted to the argument type of the pojoHandlerMethod
+ inside that bean. Any regular bean can be a message-driven POJO; the only restriction is that
the handling method must have a single argument. Spring will take care of
converting message content to the expected argument type. For a JCA-based
container, the invocation will be automatically enrolled in a JTA
@@ -542,26 +539,26 @@
</section>
<section>
- <title>Transaction management</title>
+ <title>Transaction Management</title>
<para>Spring provides a declarative transaction model including
transaction propagation semantics, so that applications can declare
transaction boundaries around specific methods either through annotation
- or via XML. An example using annotations can be found in example <xref
- linkend="transactional-method-read-only" /> and, more extensively in the
- Sportsclub demo application (also, consult the user guide). It is
+ or via XML. An example using annotations can be found in <xref
+ linkend="transactional-method-read-only" /> and more extensively in the
+ Sportsclub example application. It is
important to note that the model is the same regardless whether the
- transactions being used are local transactions or JTA transactions -
+ transactions being used are local transactions or JTA transactions.
Spring will wrap components in a transactional proxy which will delegate
- to a transaction manager, which is declared separately, as a Spring bean.
+ to a transaction manager; which is declared separately as a Spring bean.
Through its PlatformTransactionManager abstraction, Spring lets developers
to choose between using resource-local transactions or delegating to the
transaction manager provided by the application server.</para>
<para>Transaction support in JBoss Enterprise Application Platform is
- provided by JBoss Transaction Service, a highly configurable and
- performant transaction manager. For using the JBoss Transaction Service in
- a Spring application, you can simply use the standard Spring JTA
+ provided by JBoss Transaction Service, a highly configurable transaction
+ manager. To use the JBoss Transaction Service in
+ a Spring application, use the standard Spring JTA
transaction manager definition.</para>
<example>
@@ -572,22 +569,22 @@
<para>The use of this transaction manager allows Spring to create JTA
transactions (for example, through Spring declarative transaction
- management) or to enroll in existing transactions, if any. It requires the
+ management), or to enroll in existing transactions, if any. It requires the
use of managed datasources, JTA-integrated session factories or
- container-deployed persistence units and ensures that the underlying
- database connections, sessions and persistence contexts are managed
- transparently and shared with other components. One of the strongest
+ container-deployed persistence units, and ensures that the underlying
+ database connections, sessions, and persistence contexts are managed
+ transparently and shared with other components. <!-- One of the strongest
arguments in favour of using JTA across the application is that it ensures
that all resources involved in a complex operation are enrolled in the
- same transaction.</para>
+ same transaction. --></para>
<simplesect>
- <title>JTA and messaging integration</title>
+ <title>JTA and Messaging Integration</title>
<para>As described in <xref linkend="messaging_integration" />, the
recommended integration method for receiving JMS messages is through a
JCA-endpoint based MessageListenerContainer. The processing of a message
- (i.e. during the call to the message handling method) is wrapped in a
+ (that is, during the call to the message handling method) is wrapped in a
JTA transaction. As a result, any other JTA-aware resources
(datasources, entity manager factories, session factories, JMS sessions)
will participate in the same transaction.</para>
@@ -601,9 +598,9 @@
</section>
<section>
- <title>EJB integration</title>
+ <title>EJB Integration</title>
- <para>Although there is a great deal of overlap between EJB and Spring,
+ <para>Although there is overlap between EJB and Spring,
mixing the two component models together is a frequently encountered
scenario. It consists of having components of one type delegating
functionality to components of the other type. The best practice is to
@@ -611,9 +608,9 @@
direction (Spring to EJB and EJB to Spring).</para>
<section>
- <title>Injecting Spring beans into EJBs</title>
+ <title>Injecting Spring Beans Into EJBs</title>
- <para>For JBoss EAP 5 there are two major options of injecting Spring
+ <para>For JBoss Enterprise Application Platform 5 there are two major options of injecting Spring
beans into EJBs:</para>
<itemizedlist>
@@ -627,7 +624,7 @@
</itemizedlist>
<simplesect>
- <title>Using Spring's native support for EJB integration</title>
+ <title>Using Spring's Native Support for EJB Integration</title>
<para>Spring supports injection into EJBs through its
SpringBeanAutowiringInterceptor, which honours the @Autowired
@@ -637,7 +634,7 @@
<title>Injecting a Spring Bean into EJBs using Spring's native
support</title>
- <programlisting language="java">@Stateless
+ <programlisting language="Java">@Stateless
@Interceptors(SpringBeanAutowiringInterceptor.class)
public class InjectedEjbImpl implements InjectedEjb {
@@ -650,8 +647,8 @@
<para>The injected Spring beans are retrieved from an
ApplicationContext located using a ContextSingletonBeanFactoryLocator,
which uses a two-step method for locating contexts. It relies on the
- existence of one or more files named beanRefContext.xml on the
- classpath (otherwise said, it performs a
+ existence of one or more files named <filename>beanRefContext.xml</filename> on the
+ classpath (in other words, it performs a
'classpath*:beanRefContext.xml' lookup), which contains a single
application context definition. Example <xref
linkend="singletonBFL" /> contains the definition of such a
@@ -662,13 +659,13 @@
ContextSingletonBeanFactoryLocator and the corresponding
simpleContext.xml</title>
- <programlisting language="xml"><beans>
+ <programlisting language="XML"><beans>
<bean class="org.springframework.context.support.ClassPathXmlApplicationContext">
<constructor-arg value="classpath*:simpleContext.xml" />
</bean>
</beans</programlisting>
- <programlisting language="xml"><beans>
+ <programlisting language="XML"><beans>
<bean id="springBean" class="example.SpringBean"/>
</beans></programlisting>
@@ -682,24 +679,25 @@
<title>Using Snowdrop</title>
<para>Snowdrop is a package of JBoss-specific extensions to Spring,
- which is included with WFK. This section will provide a succint
+ which is included with JBoss Web Framework Kit. This section provides an
overview on how to inject Spring beans into EJBs using Snowdrop
- support, for more details and a more elaborate example, please consult
- the Snowdrop user guide and the Sportsclub demo application.</para>
+ support. For more details and a more elaborate example, please consult
+ the <citetitle>Snowdrop User Guide</citetitle> and the
+ <citetitle>portsclub Example</citetitle>.</para>
<para>Snowdrop supports the bootstrapping of Spring application
- contexts through its JBoss-specific Spring deployer, which will
- identify Spring bean configuration files (regular application context
+ contexts through its JBoss-specific Spring deployer. This
+ identifies Spring bean configuration files (regular application context
XML definitions) which are deployed in the META-INF directory of a
deployable module (EAR, WAR, or EJB-JAR) and match a specific pattern
- (by default, *-spring.xml), will bootstrap ApplicationContexts which
+ (by default, *-spring.xml). It will bootstrap ApplicationContexts, which
are further registered in JNDI under a name which can be configured
from within the context definition.</para>
<example id="spring-deployer-xml">
<title>Spring beans configuration file (example-spring.xml)</title>
- <programlisting language="xml"><beans>
+ <programlisting language="XML"><beans>
<description>BeanFactory=(MyApp)</description>
<bean id="springBean" class="example.SpringBean"/>
</beans></programlisting>
@@ -717,7 +715,7 @@
<example>
<title>Injecting a Spring bean into an EJB using Snowdrop</title>
- <para><programlisting language="java">@Stateless
+ <para><programlisting language="Java">@Stateless
@Interceptors(SpringLifecycleInterceptor.class)
public class InjectedEjbImpl implements InjectedEjb
{
@@ -734,7 +732,7 @@
<title>Accessing EJBs from Spring beans</title>
<para>Injecting stateless EJBs in Spring components is also possible.
- There are two possible ways of achieving this:</para>
+ There are two possible ways:</para>
<itemizedlist>
<listitem>
@@ -751,9 +749,9 @@
in example <xref linkend="ejb-reference" /></para>
<example id="ejb-reference">
- <title>Definiting an EJB reference as a Spring bean</title>
+ <title>Defining an EJB reference as a Spring bean</title>
- <programlisting language="xml"><beans xmlns="http://www.springframework.org/schema/beans"
+ <programlisting language="XML"><beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:jee="http://www.springframework.org/schema/jee"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
@@ -773,7 +771,7 @@
<example>
<title>Injecting an EJB reference defined as a Spring bean</title>
- <programlisting>public class ConsumerBean {
+ <programlisting language="Java">public class ConsumerBean {
@Autowire ExampleEjb exampleEJB;
@@ -786,7 +784,7 @@
<example>
<title>Injecting an EJB using annotations</title>
- <programlisting>public class ConsumerBean {
+ <programlisting language="Java">public class ConsumerBean {
@EJB(mappedName="ejb/exampleEJB")
ExampleEjb exampleEJB;
Modified: projects/docs/enterprise/WFK/Spring_Developer_Guide/en-US/section-Section_A.xml
===================================================================
--- projects/docs/enterprise/WFK/Spring_Developer_Guide/en-US/section-Section_A.xml 2011-03-27 21:06:36 UTC (rev 111040)
+++ projects/docs/enterprise/WFK/Spring_Developer_Guide/en-US/section-Section_A.xml 2011-03-28 07:08:09 UTC (rev 111041)
@@ -7,8 +7,7 @@
<section id="Obtaining_Spring-section">
<title>Obtaining Spring</title>
- <para>You can obtain a certified version of the Spring Framework in a few
- different ways:</para>
+ <para>A certified version of Spring can be obtained in the following ways:</para>
<itemizedlist>
<listitem>
@@ -36,7 +35,7 @@
the community versions of Spring can be found in the <ulink url="http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/overview.html#dependency-management"> Spring Reference documentation </ulink>. While the instructions above have been written taking Spring 3 into consideration, they are applicable to version 2.5.6.SEC01 as well.</para>
<simplesect>
- <title>How to find the Spring JARs in a downloaded distribution</title>
+ <title>How To Find the Spring JARs in a Downloaded Distribution</title>
<para>The downloadable distributions of the Spring Framework may or may
not include dependencies required by Spring to integrate with third party
Modified: projects/docs/enterprise/WFK/Spring_Developer_Guide/en-US/section-Section_B.xml
===================================================================
--- projects/docs/enterprise/WFK/Spring_Developer_Guide/en-US/section-Section_B.xml 2011-03-27 21:06:36 UTC (rev 111040)
+++ projects/docs/enterprise/WFK/Spring_Developer_Guide/en-US/section-Section_B.xml 2011-03-28 07:08:09 UTC (rev 111041)
@@ -23,7 +23,7 @@
</listitem>
</itemizedlist>
- <para>In the following chapters, we will discuss both of these options,
+ <para>In the following chapters, both of these options are discussed,
explaining how they can be implemented, as well as their relative advantages
and disadvantages. </para>
</section>
More information about the jboss-cvs-commits
mailing list