diff --git a/spring-framework-reference/src/aop.xml b/spring-framework-reference/src/aop.xml index f90114c2bfc036a66acdfe247f31892c5c59569f..1b2e62d75c21d331c03455852627ca93f35641fb 100644 --- a/spring-framework-reference/src/aop.xml +++ b/spring-framework-reference/src/aop.xml @@ -74,7 +74,7 @@ Aspect: 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 schema-based approach) or regular classes annotated with the @Aspect @@ -211,7 +211,7 @@ 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. 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. Spring AOP will never strive to compete with AspectJ to provide a diff --git a/spring-framework-reference/src/cci.xml b/spring-framework-reference/src/cci.xml index 8b5b7561c467b0c5271f21b9b509669cf56fe4f7..d34fdfe0be1d181fee2a53b1b23cb4268b66da7e 100644 --- a/spring-framework-reference/src/cci.xml +++ b/spring-framework-reference/src/cci.xml @@ -7,15 +7,15 @@
Introduction - J2EE provides a specification to standardize access to enterprise - information systems (EIS): the JCA (Java Connector Architecture). This + 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: 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 @@ 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. @@ -84,7 +84,7 @@ 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.
@@ -760,7 +760,7 @@ interactionSpec.setInteractionVerb(ECIInteractionSpec.SYNC_SEND_RECEIVE); - In managed mode (that is, in a J2EE environment), the + In managed mode (that is, in a Java EE environment), the configuration could look as follows: <jee:jndi-lookup id="connectionFactory" jndi-name="eis/cicseci"/> @@ -941,7 +941,7 @@ MyMappingRecordOperation eisOperation = new MyMappingRecordOperation(getConnecti database with the Blackbox CCI connector. - The original version of this connector is provided by the J2EE + The original version of this connector is provided by the Java EE SDK (version 1.3), available from Sun. @@ -1025,7 +1025,7 @@ MyMappingRecordOperation eisOperation = new MyMappingRecordOperation(getConnecti <property name="connectionFactory" ref="connectionFactory"/> </bean> - In managed mode (that is, in a J2EE environment), the + In managed mode (that is, in a Java EE environment), the configuration could look as follows: <jee:jndi-lookup id="targetConnectionFactory" jndi-name="eis/blackbox"/> @@ -1120,7 +1120,7 @@ MyMappingRecordOperation eisOperation = new MyMappingRecordOperation(getConnecti <property name="connectionFactory" ref="connectionFactory"/> </bean> - In managed mode (that is, in a J2EE environment), the + In managed mode (that is, in a Java EE environment), the configuration could look as follows: <jee:jndi-lookup id="connectionFactory" jndi-name="eis/cicseci"/> @@ -1156,7 +1156,7 @@ MyMappingRecordOperation eisOperation = new MyMappingRecordOperation(getConnecti For global transactions, you can use Spring's generic transaction infrastructure to demarcate transactions, with JtaTransactionManager as backend (delegating to the - J2EE server's distributed transaction coordinator underneath). + Java EE server's distributed transaction coordinator underneath). For local transactions on a single CCI ConnectionFactory, Spring provides a diff --git a/spring-framework-reference/src/jdbc.xml b/spring-framework-reference/src/jdbc.xml index 2339442953f22f8d4e946dc5cbc476d213ebc50f..24548d9a02d9ee7017d8e01744f155d002875de7 100644 --- a/spring-framework-reference/src/jdbc.xml +++ b/spring-framework-reference/src/jdbc.xml @@ -1139,7 +1139,7 @@ jdbcTemplate.update( time. 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 DataSource bean in a Spring IoC container, or in conjunction with a simple JNDI environment. Pool-assuming Connection.close() calls will simply @@ -1159,7 +1159,7 @@ jdbcTemplate.update( target DataSource to add awareness of Spring-managed transactions. In this respect it is similar to a transactional JNDI DataSource as provided - by a J2EE server. + by a Java EE server. It should almost never be necessary or desirable to use this @@ -1189,7 +1189,7 @@ jdbcTemplate.update( Application code is required to retrieve the JDBC connection via DataSourceUtils.getConnection(DataSource) instead of - J2EE's standard DataSource.getConnection. This is + Java EE's standard DataSource.getConnection. This is recommended anyway, as it throws unchecked org.springframework.dao exceptions instead of checked SQLExceptions. All framework classes like diff --git a/spring-framework-reference/src/jms.xml b/spring-framework-reference/src/jms.xml index 2e1746797c160e5c33f7535baeda504df66e62bb..397621cd84ffcb596b8c092047bb3fa8ce5e881c 100644 --- a/spring-framework-reference/src/jms.xml +++ b/spring-framework-reference/src/jms.xml @@ -15,7 +15,7 @@ the production and consumption of messages. The JmsTemplate 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). @@ -131,7 +131,7 @@ 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 resource-ref inside the EJB or servlet deployment descriptors. To ensure the use of these features with the @@ -334,7 +334,7 @@ JmsTemplate automatically detects such transactional resources and operates on them accordingly. - In a J2EE environment, the + In a Java EE environment, the ConnectionFactory will pool Connections and Sessions, so those resources are efficiently reused across transactions. In a standalone environment, using Spring's @@ -349,7 +349,7 @@ ConnectionFactory 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.) + your Java EE server's / JMS provider's documentation.) 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 { To configure a message listener container for XA transaction participation, you'll want to configure a JtaTransactionManager (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 none (assuming - J2EE-style transaction management where the given + Java EE-style transaction management where the given ConnectionFactory is an XA-aware pool). diff --git a/spring-framework-reference/src/overview.xml b/spring-framework-reference/src/overview.xml index 4dd164b0f5f92ed66aed56022282f225e1b60559..5f329f80839ea7779d23f914b1b48a8a1349b2b2 100644 --- a/spring-framework-reference/src/overview.xml +++ b/spring-framework-reference/src/overview.xml @@ -1,8 +1,8 @@ - - Introduction + + Introduction to Spring Framework 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 @@ -
+
Dependency Injection @@ -108,7 +108,7 @@ applications.
-
+
Modules The Spring Framework contains a lot of features, which are diff --git a/spring-framework-reference/src/remoting.xml b/spring-framework-reference/src/remoting.xml index f58bf98eaa5bcb62a7c00672769eec9747eb5a77..d6b26c64501f4d35cf9d0384b6e7baa933cef55f 100644 --- a/spring-framework-reference/src/remoting.xml +++ b/spring-framework-reference/src/remoting.xml @@ -528,7 +528,7 @@ public class AccountServiceImpl implements AccountService { 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. + provider; check your Java EE server's documentation. In addition to stock support for JAX-RPC and JAX-WS in Spring Core, diff --git a/spring-framework-reference/src/testing.xml b/spring-framework-reference/src/testing.xml index fd73679e4abca3e64167e9b928221e1a378d3f89..4d6b85307819a496f9d5ffd6a33c9f6450bd487a 100644 --- a/spring-framework-reference/src/testing.xml +++ b/spring-framework-reference/src/testing.xml @@ -20,7 +20,7 @@ Unit testing 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 new operator, 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 DataSources - 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.
diff --git a/spring-framework-reference/src/view.xml b/spring-framework-reference/src/view.xml index 25ccf2ea9e39c495b88dfd926cac891f578065b2..e93f1d8db06b528a26e26ff827fb3aa4b492f63a 100644 --- a/spring-framework-reference/src/view.xml +++ b/spring-framework-reference/src/view.xml @@ -987,7 +987,7 @@ findOwnersForm.url=/WEB-INF/jsp/findOwners.jsp class="libraryfile">commons-collections.jar needs also to be available for Velocity. Typically they are included in the WEB-INF/lib 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 spring.jar in your 'WEB-INF/lib' directory too! The latest @@ -1864,7 +1864,7 @@ home.root=words 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.
diff --git a/spring-framework-reference/src/web-integration.xml b/spring-framework-reference/src/web-integration.xml index 3e05e98fe109cccfa4cf68d55453b0c942473f58..177cb2c53904aa5b00585af619f0e8d0207d1c28 100644 --- a/spring-framework-reference/src/web-integration.xml +++ b/spring-framework-reference/src/web-integration.xml @@ -81,7 +81,7 @@ Onto specifics... all that one need do is to declare a ContextLoaderListener - in the standard J2EE servlet web.xml file of one's web + in the standard Java EE servlet web.xml file of one's web application, and add a contextConfigLocation <context-param/> section (in the same file) that defines which set of Spring XML cpnfiguration files to load. @@ -611,13 +611,13 @@ While Spring has its own powerful web - layer, there are a number of unique advantages to building a J2EE + layer, 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. - A typical layered J2EE application built with + A typical 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 WebApplicationContextUtils.getApplicationContext(servletContext), where servletContext is the standard - ServletContext from the J2EE Servlet + ServletContext from the Java EE Servlet specification. As such, one simple mechanism for a page to get an instance of the UserService, for example, would be with code such as: @@ -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. + it all the way up the Java EE stack in this Tapestry application.