Replace J2EE with Java EE

String with version 5 the name of Java Platform, Enterprise Edition
changed from J2EE to Java EE. However a lot of the documentation still
uses the term J2EE.

This commit includes the following changes:

 * replace J2EE with Java EE where appropriate

This is not a blind search and replace. The following occurrences
remain unchanged:

 * references to old J2EE releases, most notably 1.3 and 1.4.
 * references to "Expert One-On-One J2EE Design and Development"
 * references to "Core J2EE patterns"
 * XML namespaces
 * package names

Issue: SPR-14811
See gh-1206
This commit is contained in:
Philippe Marschall
2016-10-14 16:24:16 +02:00
committed by Stephane Nicoll
parent 8619ad9d9a
commit ae5b0c6fb5
28 changed files with 58 additions and 58 deletions

View File

@@ -1,5 +1,5 @@
/*
* Copyright 2002-2014 the original author or authors.
* Copyright 2002-2016 the original author or authors.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
@@ -50,12 +50,12 @@ import org.springframework.transaction.support.TransactionSynchronizationManager
*
* <p>Application code is required to retrieve the transactional JMS Session via
* {@link ConnectionFactoryUtils#getTransactionalSession} instead of a standard
* J2EE-style {@link ConnectionFactory#createConnection()} call with subsequent
* Java EE-style {@link ConnectionFactory#createConnection()} call with subsequent
* Session creation. Spring's {@link org.springframework.jms.core.JmsTemplate}
* will autodetect a thread-bound Session and automatically participate in it.
*
* <p>Alternatively, you can allow application code to work with the standard
* J2EE-style lookup pattern on a ConnectionFactory, for example for legacy code
* Java EE-style lookup pattern on a ConnectionFactory, for example for legacy code
* that is not aware of Spring at all. In that case, define a
* {@link TransactionAwareConnectionFactoryProxy} for your target ConnectionFactory,
* which will automatically participate in Spring-managed transactions.

View File

@@ -180,7 +180,7 @@
A reference to the DestinationResolver strategy for resolving destination names.
Default is a DynamicDestinationResolver, using the JMS provider's queue/topic
name resolution. Alternatively, specify a reference to a JndiDestinationResolver
(typically in a J2EE environment).
(typically in a Java EE environment).
]]></xsd:documentation>
<xsd:appinfo>
<tool:annotation kind="ref">
@@ -262,7 +262,7 @@
The cache level for JMS resources: "none", "connection", "session", "consumer"
or "auto". By default ("auto"), the 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
effective default will be "none" (assuming Java EE-style transaction management
where the given ConnectionFactory is an XA-aware pool).
]]></xsd:documentation>
</xsd:annotation>
@@ -437,7 +437,7 @@
<xsd:documentation><![CDATA[
A reference to the DestinationResolver strategy for resolving destination names.
Default is to pass in the destination name Strings into the JCA ActivationSpec as-is.
Alternatively, specify a reference to a JndiDestinationResolver (typically in a J2EE
Alternatively, specify a reference to a JndiDestinationResolver (typically in a Java EE
environment, in particular if the server insists on receiving Destination objects).
]]></xsd:documentation>
<xsd:appinfo>