changed J2EE to Java EE

spring-framework-reference/src/aop.xml

@@ -74,7 +74,7 @@
         <listitem>
           <para><emphasis>Aspect</emphasis>: a modularization of a concern
           that cuts across multiple classes. Transaction management is a good
-          example of a crosscutting concern in J2EE applications. In Spring
+          example of a crosscutting concern in Java EE applications. In Spring
           AOP, aspects are implemented using regular classes (the <link
           linkend="aop-schema">schema-based approach</link>) or regular
           classes annotated with the <interfacename>@Aspect</interfacename>
@@ -211,7 +211,7 @@
 
       <para>Spring AOP is implemented in pure Java. There is no need for a
       special compilation process. Spring AOP does not need to control the
-      class loader hierarchy, and is thus suitable for use in a J2EE web
+      class loader hierarchy, and is thus suitable for use in a Java EE web
       container or application server.</para>
 
       <para>Spring AOP currently supports only method execution join points
@@ -235,7 +235,7 @@
       efficiently with Spring AOP, such as advise very fine-grained objects
       (such as domain objects typically): AspectJ is the best choice in such
       cases. However, our experience is that Spring AOP provides an excellent
-      solution to most problems in J2EE applications that are amenable to
+      solution to most problems in Java EE applications that are amenable to
       AOP.</para>
 
       <para>Spring AOP will never strive to compete with AspectJ to provide a

spring-framework-reference/src/cci.xml

@@ -7,15 +7,15 @@
   <section id="cci-introduction">
     <title>Introduction</title>
 
-    <para>J2EE provides a specification to standardize access to enterprise
-    information systems (EIS): the JCA (Java Connector Architecture). This
+    <para>Java EE provides a specification to standardize access to enterprise
+    information systems (EIS): the JCA (J2EE Connector Architecture). This
     specification is divided into several different parts:</para>
 
     <itemizedlist>
       <listitem>
         <para>SPI (Service provider interfaces) that the connector provider
         must implement. These interfaces constitute a resource adapter which
-        can be deployed on a J2EE application server. In such a scenario, the
+        can be deployed on a Java EE application server. In such a scenario, the
         server manages connection pooling, transaction and security (managed
         mode). The application server is also responsible for managing the
         configuration, which is held outside the client application. A
@@ -38,7 +38,7 @@
     <note>
       <para>The client side of connectors doesn't alway use CCI. Some
       connectors expose their own APIs, only providing JCA resource adapter to
-      use the system contracts of a J2EE container (connection pooling, global
+      use the system contracts of a Java EE container (connection pooling, global
       transactions, security). Spring does not offer special support for such
       connector-specific APIs.</para>
     </note>
@@ -84,7 +84,7 @@
         <para>When you use a connector in non-managed mode, you can't use
         global transactions because the resource is never enlisted / delisted
         in the current global transaction of the current thread. The resource
-        is simply not aware of any global J2EE transactions that might be
+        is simply not aware of any global Java EE transactions that might be
         running.</para>
       </note>
     </section>
@@ -760,7 +760,7 @@ interactionSpec.setInteractionVerb(ECIInteractionSpec.SYNC_SEND_RECEIVE);</progr
   &lt;property name="connectionFactory" ref="connectionFactory"/&gt;
 &lt;/bean&gt;</programlisting>
 
-      <para>In managed mode (that is, in a J2EE environment), the
+      <para>In managed mode (that is, in a Java EE environment), the
       configuration could look as follows:</para>
 
       <programlisting language="xml">&lt;jee:jndi-lookup id="connectionFactory" jndi-name="eis/cicseci"/&gt;
@@ -941,7 +941,7 @@ MyMappingRecordOperation eisOperation = new MyMappingRecordOperation(getConnecti
       database with the Blackbox CCI connector.</para>
 
       <note>
-        <para>The original version of this connector is provided by the J2EE
+        <para>The original version of this connector is provided by the Java EE
         SDK (version 1.3), available from Sun.</para>
       </note>
 
@@ -1025,7 +1025,7 @@ MyMappingRecordOperation eisOperation = new MyMappingRecordOperation(getConnecti
   &lt;property name="connectionFactory" ref="connectionFactory"/&gt;
 &lt;/bean&gt;</programlisting>
 
-      <para>In managed mode (that is, in a J2EE environment), the
+      <para>In managed mode (that is, in a Java EE environment), the
       configuration could look as follows:</para>
 
       <programlisting language="xml">&lt;jee:jndi-lookup id="targetConnectionFactory" jndi-name="eis/blackbox"/&gt;
@@ -1120,7 +1120,7 @@ MyMappingRecordOperation eisOperation = new MyMappingRecordOperation(getConnecti
   &lt;property name="connectionFactory" ref="connectionFactory"/&gt;
 &lt;/bean&gt;</programlisting>
 
-      <para>In managed mode (that is, in a J2EE environment), the
+      <para>In managed mode (that is, in a Java EE environment), the
       configuration could look as follows:</para>
 
       <programlisting language="xml">&lt;jee:jndi-lookup id="connectionFactory" jndi-name="eis/cicseci"/&gt;
@@ -1156,7 +1156,7 @@ MyMappingRecordOperation eisOperation = new MyMappingRecordOperation(getConnecti
     <para>For global transactions, you can use Spring's generic transaction
     infrastructure to demarcate transactions, with
     <classname>JtaTransactionManager</classname> as backend (delegating to the
-    J2EE server's distributed transaction coordinator underneath).</para>
+    Java EE server's distributed transaction coordinator underneath).</para>
 
     <para>For local transactions on a single CCI
     <interfacename>ConnectionFactory</interfacename>, Spring provides a

spring-framework-reference/src/jdbc.xml

@@ -1139,7 +1139,7 @@ jdbcTemplate.update(
       time.</para>
 
       <para>This is potentially useful for test or standalone environments
-      outside of a J2EE container, either as a
+      outside of a Java EE container, either as a
       <interfacename>DataSource</interfacename> bean in a Spring IoC
       container, or in conjunction with a simple JNDI environment.
       Pool-assuming <literal>Connection.close()</literal> calls will simply
@@ -1159,7 +1159,7 @@ jdbcTemplate.update(
       target <interfacename>DataSource</interfacename> to add awareness of
       Spring-managed transactions. In this respect it is similar to a
       transactional JNDI <interfacename>DataSource</interfacename> as provided
-      by a J2EE server.</para>
+      by a Java EE server.</para>
 
       <note>
         <para>It should almost never be necessary or desirable to use this
@@ -1189,7 +1189,7 @@ jdbcTemplate.update(
 
       <para>Application code is required to retrieve the JDBC connection via
       <literal>DataSourceUtils.getConnection(DataSource)</literal> instead of
-      J2EE's standard <literal>DataSource.getConnection</literal>. This is
+      Java EE's standard <literal>DataSource.getConnection</literal>. This is
       recommended anyway, as it throws unchecked
       <literal>org.springframework.dao</literal> exceptions instead of checked
       <exceptionname>SQLExceptions</exceptionname>. All framework classes like

spring-framework-reference/src/jms.xml

@@ -15,7 +15,7 @@
     the production and consumption of messages. The
     <classname>JmsTemplate</classname> class is used for message production
     and synchronous message reception. For asynchronous reception similar to
-    J2EE's message-driven bean style, Spring provides a number of message
+    Java EE's message-driven bean style, Spring provides a number of message
     listener containers that are used to create Message-Driven POJOs
     (MDPs).</para>
 
@@ -131,7 +131,7 @@
       <para>When using JMS inside an EJB, the vendor provides implementations
       of the JMS interfaces so that they can participate in declarative
       transaction management and perform pooling of connections and session.
-      In order to use this implementation, J2EE containers typically require
+      In order to use this implementation, Java EE containers typically require
       that you declare a JMS connection factory as a
       <property>resource-ref</property> inside the EJB or servlet deployment
       descriptors. To ensure the use of these features with the
@@ -334,7 +334,7 @@
       <classname>JmsTemplate</classname> automatically detects such
       transactional resources and operates on them accordingly.</para>
 
-      <para>In a J2EE environment, the
+      <para>In a Java EE environment, the
       <classname>ConnectionFactory</classname> will pool Connections and
       Sessions, so those resources are efficiently reused across transactions.
       In a standalone environment, using Spring's
@@ -349,7 +349,7 @@
       <classname>ConnectionFactory</classname> for performing distributed
       transactions. Note that this requires the use of a JTA transaction
       manager as well as a properly XA-configured ConnectionFactory! (Check
-      your J2EE server's / JMS provider's documentation.)</para>
+      your Java EE server's / JMS provider's documentation.)</para>
 
       <para>Reusing code across a managed and unmanaged transactional
       environment can be confusing when using the JMS API to create a
@@ -801,9 +801,9 @@ public interface SessionAwareMessageListener {
       <para>To configure a message listener container for XA transaction
       participation, you'll want to configure a
       <classname>JtaTransactionManager</classname> (which, by default,
-      delegates to the J2EE server's transaction subsystem). Note that the
+      delegates to the Java EE server's transaction subsystem). Note that the
       underlying JMS ConnectionFactory needs to be XA-capable and properly
-      registered with your JTA transaction coordinator! (Check your J2EE
+      registered with your JTA transaction coordinator! (Check your Java EE
       server's configuration of JNDI resources.) This allows message recepton
       as well as e.g. database access to be part of the same transaction (with
       unified commit semantics, at the expense of XA transaction log
@@ -1157,7 +1157,7 @@ http://www.springframework.org/schema/beans http://www.springframework.org/schem
             cache level will effectively be "consumer", unless an external
             transaction manager has been specified - in which case the
             effective default will be <literal>none</literal> (assuming
-            J2EE-style transaction management where the given
+            Java EE-style transaction management where the given
             ConnectionFactory is an XA-aware pool).</para></entry>
           </row>
 

spring-framework-reference/src/overview.xml

 <?xml version="1.0" encoding="UTF-8"?>
 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
 "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">
-<chapter id="introduction">
-  <title>Introduction</title>
+<chapter id="overview">
+  <title>Introduction to Spring Framework</title>
 
   <para>Fundamentally, what is Spring? We think of it as a Platform for your
   Java code. It provides comprehensive infrastructural support for developing
@@ -39,7 +39,7 @@
     </listitem>
   </itemizedlist>
 
-  <section id="introduction-dependency-injection">
+  <section id="overview-dependency-injection">
     <title>Dependency Injection</title>
 
     <sidebar id="background-ioc">
@@ -108,7 +108,7 @@
     applications.</para>
   </section>
 
-  <section id="introduction-modules">
+  <section id="overview-modules">
     <title>Modules</title>
 
     <para>The Spring Framework contains a lot of features, which are

spring-framework-reference/src/remoting.xml

@@ -528,7 +528,7 @@ public class AccountServiceImpl implements AccountService {
       <para>Spring can work with both standard Java web services APIs. On Java
       EE 5 / Java 6, the obvious choice is JAX-WS. On J2EE 1.4 environments
       that run on Java 5, you might have the option to plug in a JAX-WS
-      provider; check your J2EE server's documentation.</para>
+      provider; check your Java EE server's documentation.</para>
     </note>
 
     <para>In addition to stock support for JAX-RPC and JAX-WS in Spring Core,

spring-framework-reference/src/testing.xml

@@ -20,7 +20,7 @@
     <title>Unit testing</title>
 
     <para>One of the main benefits of Dependency Injection is that your code
-    should really depend far less on the container than in traditional J2EE
+    should really depend far less on the container than in traditional Java EE
     development. The POJOs that make up your application should be testable in
     JUnit or TestNG tests, with objects simply instantiated using the
     <literal>new</literal> operator, <emphasis>without Spring or any other
@@ -54,7 +54,7 @@
         contains an implementation of the JNDI SPI, which is useful for
         setting up a simple JNDI environment for test suites or stand-alone
         applications. If, for example, JDBC <classname>DataSource</classname>s
-        get bound to the same JNDI names in test code as within a J2EE
+        get bound to the same JNDI names in test code as within a Java EE
         container, both application code and configuration can be reused in
         testing scenarios without modification.</para>
       </section>

spring-framework-reference/src/view.xml

@@ -987,7 +987,7 @@ findOwnersForm.url=/WEB-INF/jsp/findOwners.jsp
       class="libraryfile">commons-collections.jar</filename> needs also to be
       available for Velocity. Typically they are included in the
       <literal>WEB-INF/lib</literal> folder where they are guaranteed to be
-      found by a J2EE server and added to the classpath for your application.
+      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
       class="libraryfile">spring.jar</filename> in your <filename
       class="directory">'WEB-INF/lib'</filename> directory too! The latest
@@ -1864,7 +1864,7 @@ home.root=words</programlisting>
 
       <para>You will also need to ensure that an XML parser and an XSLT engine
       are available on the classpath. JDK 1.4 provides them by default, and
-      most J2EE containers will also make them available by default, but it's
+      most Java EE containers will also make them available by default, but it's
       a possible source of errors to be aware of.</para>
     </section>
   </section>

spring-framework-reference/src/web-integration.xml

@@ -81,7 +81,7 @@
 
     <para>Onto specifics... all that one need do is to declare a <ulink
     url="http://static.springframework.org/spring/docs/2.5.x/api/org/springframework/web/context/ContextLoaderListener.html"><classname>ContextLoaderListener</classname></ulink>
-    in the standard J2EE servlet <literal>web.xml</literal> file of one's web
+    in the standard Java EE servlet <literal>web.xml</literal> file of one's web
     application, and add a <literal>contextConfigLocation</literal>
     &lt;context-param/&gt; section (in the same file) that defines which set
     of Spring XML cpnfiguration files to load.</para>
@@ -611,13 +611,13 @@
     </quote>
 
     <para>While Spring has its own <link linkend="mvc">powerful web
-    layer</link>, there are a number of unique advantages to building a J2EE
+    layer</link>, there are a number of unique advantages to building a Java EE
     application using a combination of Tapestry for the web user interface and
     the Spring container for the lower layers. This section of the web
     integration chapter attempts to detail a few best practices for combining
     these two frameworks.</para>
 
-    <para>A <emphasis>typical</emphasis> layered J2EE application built with
+    <para>A <emphasis>typical</emphasis> layered Java EE application built with
     Tapestry and Spring will consist of a top user interface (UI) layer built
     with Tapestry, and a number of lower layers, all wired together by one or
     more Spring containers. Tapestry's own reference documentation contains
@@ -728,7 +728,7 @@ http://www.springframework.org/schema/beans http://www.springframework.org/schem
       application by calling Spring's static utility function
       <literal>WebApplicationContextUtils.getApplicationContext(servletContext)</literal>,
       where servletContext is the standard
-      <interface>ServletContext</interface> from the J2EE Servlet
+      <interface>ServletContext</interface> from the Java EE Servlet
       specification. As such, one simple mechanism for a page to get an
       instance of the <interfacename>UserService</interfacename>, for example,
       would be with code such as:</para>
@@ -1096,7 +1096,7 @@ public abstract class Login extends BasePage implements ErrorProperty, PageRende
     are coming from, and in fact it is easy to slip in another implementation,
     for example, during testing. This inversion of control is one of the prime
     goals and benefits of the Spring Framework, and we have managed to extend
-    it all the way up the J2EE stack in this Tapestry application.</para>
+    it all the way up the Java EE stack in this Tapestry application.</para>
   </section>
 
   <section id="web-integration-resources">