提交 bf4b9f5f 编写于 作者: C Chris Beams

Replace 'Java EE' with 'enterprise Java' as appropriate

Also change 'JEE' -> 'Java EE'
上级 06259900
......@@ -74,9 +74,9 @@
<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 Java EE applications. In Spring
AOP, aspects are implemented using regular classes (the <link
linkend="aop-schema">schema-based approach</link>) or regular
example of a crosscutting concern in enterprise Java 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>
annotation (the <link
linkend="aop-ataspectj"><interfacename>@AspectJ</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 Java EE web
class loader hierarchy, and is thus suitable for use in a Servlet
container or application server.</para>
<para>Spring AOP currently supports only method execution join points
......@@ -235,8 +235,8 @@
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 Java EE applications that are amenable to
AOP.</para>
solution to most problems in enterprise Java applications that are
amenable to AOP.</para>
<para>Spring AOP will never strive to compete with AspectJ to provide a
comprehensive AOP solution. We believe that both proxy-based frameworks
......
......@@ -5206,8 +5206,8 @@ public @interface MovieQualifier {
<para>Spring also supports injection using the JSR-250
<interfacename>@Resource</interfacename> annotation on fields or bean
property setter methods. This is a common pattern in Java EE 5 and Java
6, for example, in JSF 1.2 managed beans or JAX-WS 2.0 endpoints. Spring
property setter methods. This is a common pattern in Java EE 5 and 6,
for example in JSF 1.2 managed beans or JAX-WS 2.0 endpoints. Spring
supports this pattern for Spring-managed objects as well.</para>
<para><interfacename>@Resource</interfacename> takes a name attribute,
......
......@@ -169,8 +169,8 @@ TR: OK AS IS - I think it's fine as is - the concepts apply to both programmatic
management?</title>
<para>The Spring Framework's transaction management support changes
traditional rules as to when a Java EE application requires an
application server.</para>
traditional rules as to when a enterprise Java application requires
an application server.</para>
<para>In particular, you do not need an application server simply for
declarative transactions through EJBs. In fact, even if your
......
......@@ -607,19 +607,19 @@
</para>
<para>While Spring has its own <link linkend="mvc">powerful web
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 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
the following snippet of best practice advice. (Text that the author of
this Spring section has added is contained within <literal>[]</literal>
brackets.)</para>
layer</link>, there are a number of unique advantages to building an
enterprise Java 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 enterprise Java 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 the following snippet of best practice advice. (Text that the
author of this Spring section has added is contained within
<literal>[]</literal> brackets.)</para>
<para>
<quote>
......@@ -1092,7 +1092,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 Java EE stack in this Tapestry application.</para>
it throughout the stack in this Tapestry application.</para>
</section>
</section>
......
......@@ -466,7 +466,7 @@ public class Client {
</section>
<section id="xsd-config-body-schemas-jee">
<title>The <literal>jee</literal> schema</title>
<para>The <literal>jee</literal> tags deal with JEE (Java Enterprise Edition)-related
<para>The <literal>jee</literal> tags deal with Java EE (Java Enterprise Edition)-related
configuration issues, such as looking up a JNDI object and defining EJB references.</para>
<para>To use the tags in the <literal>jee</literal> schema, you need to have
the following preamble at the top of your Spring XML configuration file;
......
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册