Seam contexts are created and destroyed by the framework. The application does not control context demarcation via explicit Java API calls. Context are usually implicit. In some cases, however, contexts are demarcated via annotations.

Seam上下文由Seam框架创建和销毁。应用并不显式调用Java API来控制上下文的划分。上下文通常都是隐含的。在某些情况下，上下文通过注释来划分。

The basic Seam contexts are:

基本的Seam上下文包括：

You will recognize some of these contexts from servlet and related specifications. However, two of them might be new to you: conversation context, and business process context. One reason state management in web applications is so fragile and error-prone is that the three built-in contexts (request, session and application) are not especially meaningful from the point of view of the business logic.

你可能很快就能认出一些Servlet和相关规范中的上下文。但是有两个上下文你可能头一次遇到：对话上下文和业务流程上下文。Web应用的状态管理非常脆弱和容易出错的一个原因就是Web内置的上下文（请求，会话和应用）从业务流程的角度上来看并没有特别的意义。

A user login session, for example, is a fairly arbitrary construct in terms of the actual application work flow. Therefore, most Seam components are scoped to the conversation or business process contexts, since they are the contexts which are most meaningful in terms of the application.

例如，一个用户登录的会话，按照实际的应用工作流来说，是一个相当武断的构造。因此，大部分Seam组件都被指定在对话或者业务流程的上下文范围内，因为这些上下文更加具有应用意义。

Let's look at each context in turn.

让我们来依次看看每个上下文。

User user = (User) Contexts.getSessionContext().get("user");

Contexts.getSessionContext().set("user", user);

Seam components are POJOs (Plain Old Java Objects). In particular, they are JavaBeans or EJB 3.0 enterprise beans. While Seam does not require that components be EJBs and can even be used without an EJB 3.0 compliant container, Seam was designed with EJB 3.0 in mind and includes deep integration with EJB 3.0. Seam supports the following component types.

Seam组件是POJOs(普通的Java对象)。特别的，它们也可以是JavaBeans或者EJB3.0企业Bean。虽然Seam不要求组件是EJB甚至根本不需要EJB3.0兼容的容器，但是Seam是按照EJB3.0设计的，并且非常深的整合了EJB3.0。Seam支持下面的组件类型：

@Stateless
@Interceptors(SeamInterceptor.class)
public class LoginAction implements Login { 
    ... 
}

<interceptors>
   <interceptor>
      <interceptor-class>org.jboss.seam.ejb.SeamInterceptor</interceptor-class>
   </interceptor>
</interceptors>
   
<assembly-descriptor>
   <interceptor-binding>
      <ejb-name>*</ejb-name>
      <interceptor-class>org.jboss.seam.ejb.SeamInterceptor</interceptor-class>
   </interceptor-binding>
</assembly-descriptor>

@Name("loginAction")
@Stateless
public class LoginAction implements Login { 
    ... 
}

@Name("com.jboss.myapp.loginAction")
@Stateless
public class LoginAction implements Login { 
    ... 
}

<h:commandButton type="submit" value="Login"
                 action="#{com.jboss.myapp.loginAction.login}"/>

<factory name="loginAction" scope="STATELESS" value="#{com.jboss.myapp.loginAction}"/>

@Name("user")
@Entity
@Scope(SESSION)
public class User { 
    ... 
}

@Name("user")
@Entity
@Scope(CONVERSATION)
@Role(name="currentUser", scope=SESSION)
public class User { 
    ... 
}

@Name("user")
@Entity
@Scope(CONVERSATION)
@Roles({@Role(name="currentUser", scope=SESSION),
        @Role(name="tempUser", scope=EVENT)})
public class User { 
    ... 
}

FacesMessages.instance().add("Welcome back, #{user.name}!");

Dependency injection or inversion of control is by now a familiar concept to most Java developers. Dependency injection allows a component to obtain a reference to another component by having the container "inject" the other component to a setter method or instance variable.

现在每个Java开发者都非常熟悉依赖注入或反转控制这些概念。依赖注入允许一个组件通过容器”注入“的方式获得另一个组件的引用，容器将另外的的组件注入setter或者实例变量中。

In all dependency injection implementations that we have seen, injection occurs when the component is constructed, and the reference does not subsequently change for the lifetime of the component instance. For stateless components, this is reasonable. From the point of view of a client, all instances of a particular stateless component are interchangeable.

在我们看到的所有依赖注入的实现中，注入发生在组件被构造时，在组件实例的生命周期内引用不能改变。对于无状态的组件来说，这是有道理的。从客户角度出发，一个特定的无状态的组件的所有实例都可以互换。

On the other hand, Seam emphasizes the use of stateful components. So traditional dependency injection is no longer a very useful construct. Seam introduces the notion of bijection as a generalization of injection. In contrast to injection, bijection is:

另一方面，Seam强调使用有状态的组件。所以传统的依赖注入不再是非常有用的构造了。Seam引入了注入的泛化概念双向注射。对比注入，双向注射是：

In essence, bijection lets you alias a context variable to a component instance variable, by specifying that the value of the instance variable is injected, outjected, or both. Of course, we use annotations to enable bijection.

本质上说，双向注射能够让你通过指定实例变量的值是注入，还是注出或者两者都是，从而将一个上下文变量别名为一个组件的实例变量。当然，我们使用注释来完成双向注射。

The @In annotation specifies that a value should be injected, either into an instance variable:

@In注释指定一个值应该被注入到一个实例变量

@Name("loginAction")
@Stateless
public class LoginAction implements Login { 
    @In User user;
    ... 
}

or into a setter method:

或者注入到一个setter方法中：

@Name("loginAction")
@Stateless
public class LoginAction implements Login { 
    User user;
    
    @In
    public void setUser(User user) {
        this.user=user;
    }
    
    ... 
}

By default, Seam will do a priority search of all contexts, using the name of the property or instance variable that is being injected. You may wish to specify the context variable name explicitly, using, for example, @In("currentUser").

在默认情况下，Seam将使用注入的实例或者属性的名字对所有的上下文进行优先搜索。你可以显式的指定上下文变量的名字。例如@In("currentUser").

If you want Seam to create an instance of the component when there is no existing component instance bound to the named context variable, you should specify @In(create=true). If the value is optional (it can be null), specify @In(required=false).

For some components, it can be repetitive to have to specify @In(create=true) everywhere they are used. In such cases, you can annotate the component @AutoCreate, and then it will always be created, whenever needed, even without the explicit use of create=true.

You can even inject the value of an expression:

@Name("loginAction")
@Stateless
public class LoginAction implements Login { 
    @In("#{user.username}") String username;
    ... 
}

(There is much more information about component lifecycle and injection in the next chapter.)

The @Out annotation specifies that an attribute should be outjected, either from an instance variable:

@Name("loginAction")
@Stateless
public class LoginAction implements Login { 
    @Out User user;
    ... 
}

or from a getter method:

@Name("loginAction")
@Stateless
public class LoginAction implements Login { 
    User user;
    
    @Out
    public User getUser() {
        return user;
    }
    
    ... 
}

An attribute may be both injected and outjected:

@Name("loginAction")
@Stateless
public class LoginAction implements Login { 
    @In @Out User user;
    ... 
}

or:

@Name("loginAction")
@Stateless
public class LoginAction implements Login { 
    User user;
    
    @In
    public void setUser(User user) {
        this.user=user;
    }
    
    @Out
    public User getUser() {
        return user;
    }
    
    ... 
}

Session bean and entity bean Seam components support all the usual EJB 3.0 lifecycle callback (@PostConstruct, @PreDestroy, etc). But Seam also supports the use of any of these callbacks with JavaBean components. However, since these annotations are not available in a J2EE environment, Seam defines two additional component lifecycle callbacks, equivalent to @PostConstruct and @PreDestroy.

The @Create method is called after Seam instantiates a component. Components may define only one @Create method.

The @Destroy method is called when the context that the Seam component is bound to ends. Components may define only one @Destroy method.

In addition, stateful session bean components must define a method with no parameters annotated @Remove. This method is called by Seam when the context ends.

Finally, a related annotation is the @Startup annotation, which may be applied to any application or session scoped component. The @Startup annotation tells Seam to instantiate the component immediately, when the context begins, instead of waiting until it is first referenced by a client. It is possible to control the order of instantiation of startup components by specifying @Startup(depends={....}).

The @Install annotation lets you control conditional installation of components that are required in some deployment scenarios and not in others. This is useful if:

@Install works by letting you specify precedence and dependencies.

The precedence of a component is a number that Seam uses to decide which component to install when there are multiple classes with the same component name in the classpath. Seam will choose the component with the higher precendence. There are some predefined precedence values (in ascending order):

Suppose we have a component named messageSender that talks to a JMS queue.

@Name("messageSender") 
public class MessageSender {
    public void sendMessage() {
        //do something with JMS
    }
}

In our unit tests, we don't have a JMS queue available, so we would like to stub out this method. We'll create a mock component that exists in the classpath when unit tests are running, but is never deployed with the application:

@Name("messageSender") 
@Install(precedence=MOCK)
public class MockMessageSender extends MessageSender {
    public void sendMessage() {
        //do nothing!
    }
}

The precedence helps Seam decide which version to use when it finds both components in the classpath.

This is nice if we are able to control exactly which classes are in the classpath. But if I'm writing a reusable framework with many dependecies, I don't want to have to break that framework across many jars. I want to be able to decide which components to install depending upon what other components are installed, and upon what classes are available in the classpath. The @Install annotation also controls this functionality. Seam uses this mechanism internally to enable conditional installation of many of the built-in components. However, you probably won't need to use it in your application.

Who is not totally fed up with seeing noisy code like this?

private static final Log log = LogFactory.getLog(CreateOrderAction.class);
        
public Order createOrder(User user, Product product, int quantity) {
    if ( log.isDebugEnabled() ) {
        log.debug("Creating new order for user: " + user.username() + 
            " product: " + product.name() 
            + " quantity: " + quantity);
    }
    return new Order(user, product, quantity);
}

It is difficult to imagine how the code for a simple log message could possibly be more verbose. There is more lines of code tied up in logging than in the actual business logic! I remain totally astonished that the Java community has not come up with anything better in 10 years.

Seam provides a logging API that simplifies this code significantly:

@Logger private Log log;
        
public Order createOrder(User user, Product product, int quantity) {
    log.debug("Creating new order for user: #0 product: #1 quantity: #2", user.username(), product.name(), quantity);
    return new Order(user, product, quantity);
}

It doesn't matter if you declare the log variable static or not—it will work either way, except for entity bean components which require the log variable to be static.

Note that we don't need the noisy if ( log.isDebugEnabled() ) guard, since string concatenation happens inside the debug() method. Note also that we don't usually need to specify the log category explicitly, since Seam knows what component it is injecting the Log into.

If User and Product are Seam components available in the current contexts, it gets even better:

@Logger private Log log;
        
public Order createOrder(User user, Product product, int quantity) {
    log.debug("Creating new order for user: #{user.username} product: #{product.name} quantity: #0", quantity);
    return new Order(user, product, quantity);
}

Seam logging automagically chooses whether to send output to log4j or JDK logging. If log4j is in the classpath, Seam with use it. If it is not, Seam will use JDK logging.

Many application servers feature an amazingly broken implementation of HttpSession clustering, where changes to the state of mutable objects bound to the session are only replicated when the application calls setAttribute() explicitly. This is a source of bugs that can not effectively be tested for at development time, since they will only manifest when failover occurs. Furthermore, the actual replication message contains the entire serialized object graph bound to the session attribute, which is inefficient.

Of course, EJB stateful session beans must perform automatic dirty checking and replication of mutable state and a sophisticated EJB container can introduce optimizations such as attribute-level replication. Unfortunately, not all Seam users have the good fortune to be working in an environment that supports EJB 3.0. So, for session and conversation scoped JavaBean and entity bean components, Seam provides an extra layer of cluster-safe state management over the top of the web container session clustering.

For session or conversation scoped JavaBean components, Seam automatically forces replication to occur by calling setAttribute() once in every request that the component was invoked by the application. Of course, this strategy is inefficient for read-mostly components. You can control this behavior by implementing the org.jboss.seam.core.Mutable interface, or by extending org.jboss.seam.core.AbstractMutable, and writing your own dirty-checking logic inside the component. For example,

@Name("account")
public class Account extends AbstractMutable
{
    private BigDecimal balance;
    
    public void setBalance(BigDecimal balance)
    {
        setDirty(this.balance, balance);
        this.balance = balance;
    }
    
    public BigDecimal getBalance()
    {
        return balance;
    }
    
    ...
    
}

Or, you can use the @ReadOnly annotation to achieve a similar effect:

@Name("account")
public class Account
{
    private BigDecimal balance;
    
    public void setBalance(BigDecimal balance)
    {
        this.balance = balance;
    }
    
    @ReadOnly
    public BigDecimal getBalance()
    {
        return balance;
    }
    
    ...
    
}

For session or conversation scoped entity bean components, Seam automatically forces replication to occur by calling setAttribute() once in every request, unless the (conversation-scoped) entity is currently associated with a Seam-managed persistence context, in which case no replication is needed. This strategy is not necessarily efficient, so session or conversation scope entity beans should be used with care. You can always write a stateful session bean or JavaBean component to "manage" the entity bean instance. For example,

@Stateful
@Name("account")
public class AccountManager extends AbstractMutable
{
    private Account account; // an entity bean
    
    @Unwrap
    public void getAccount()
    {
        return account;
    }
    
    ...
    
}

Note that the EntityHome class in the Seam Application Framework provides a great example of managing an entity bean instance using a Seam component.

We often need to work with objects that are not Seam components. But we still want to be able to inject them into our components using @In and use them in value and method binding expressions, etc. Sometimes, we even need to tie them into the Seam context lifecycle (@Destroy, for example). So the Seam contexts can contain objects which are not Seam components, and Seam provides a couple of nice features that make it easier to work with non-component objects bound to contexts.

The factory component pattern lets a Seam component act as the instantiator for a non-component object. A factory method will be called when a context variable is referenced but has no value bound to it. We define factory methods using the @Factory annotation. The factory method binds a value to the context variable, and determines the scope of the bound value. There are two styles of factory method. The first style returns a value, which is bound to the context by Seam:

@Factory(scope=CONVERSATION)
public List<Customer> getCustomerList() { 
    return ... ;
} 

The second style is a method of type void which binds the value to the context variable itself:

@DataModel List<Customer> customerList;

@Factory("customerList")
public void initCustomerList() { 
    customerList = ...  ;
} 

In both cases, the factory method is called when we reference the customerList context variable and its value is null, and then has no further part to play in the lifecycle of the value. An even more powerful pattern is the manager component pattern. In this case, we have a Seam component that is bound to a context variable, that manages the value of the context variable, while remaining invisible to clients.

A manager component is any component with an @Unwrap method. This method returns the value that will be visable to clients, and is called every time a context variable is referenced.

@Name("customerList")
@Scope(CONVERSATION)
public class CustomerListManager
{
    ...
    
    @Unwrap
    public List<Customer> getCustomerList() { 
        return ... ;
    }
}

The manager component pattern is especially useful if we have an object where you need more control over the lifecycle of the component. For example, if you have a heavyweight object that needs a cleanup operation when the context ends you could @Unwrap the object, and perform cleanup in the @Destroy method of the manager component.

@Name("hens")
@Scope(APPLICATION) 
public class HenHouse {
    
    private Set<Hen> hens;
    
    @Unwrap
    public List<Hen> getHens() {
        if (hens == null) {
            // Setup our hens
        }
        return hens;
    }
    
    @Observer({"chickBorn", "chickenBoughtAtMarket"})
    public addHen() {
        hens.add(hen);
    }
    
    @Observer("chickenSoldAtMarket")
    public removeHen() {
        hens.remove(hen);
    }
    
    @Observer("foxGetsIn")
    public addHen() {
        hens.clear();
    }
    ...
} 

Here the managed component observes many events which change the underlying object. The component manages these actions itself, and because the object is unwrapped on every access, a consistent view is provided.

One kind of "stuff"  只有一种工具

Seam defines a uniform component model for all business logic in your application. A Seam component may be stateful, with the state associated with any one of several well-defined contexts, including the long-running, persistent, business process context and the conversation context, which is preserved across multiple web requests in a user interaction.

Seam为你的应用程序中所有的商业逻辑定义了一种统一的组件模型。一个Seam组件可能是有状态的，这种状态可以和任何定义良好的上下文相关联，这些上下文包括长时间运行上下文，持久化上下文，商业过程上下文和在用户交互中能够跨越多个Web请求的会话上下文。

There is no distinction between presentation tier components and business logic components in Seam. You can layer your application according to whatever architecture you devise, rather than being forced to shoehorn your application logic into an unnatural layering scheme forced upon you by whatever combination of stovepipe frameworks you're using today.

Seam中的组件并不区分表现层组件和业务逻辑组件。你可以根据任何你设计的体系来将你的应用程序分层，而非必须削足适履的将你的程序逻辑被迫按照某种分层机制才能和你目前使用的框架相结合。

Unlike plain Java EE or J2EE components, Seam components may simultaneously access state associated with the web request and state held in transactional resources (without the need to propagate web request state manually via method parameters). You might object that the application layering imposed upon you by the old J2EE platform was a Good Thing. Well, nothing stops you creating an equivalent layered architecture using Seam—the difference is that you get to architect your own application and decide what the layers are and how they work together.

          和普通的Java EE或者J2EE组件不同，Seam组件可以同时访问Web请求相关的状态和事务性资源持有的状态（不必手工的通过方法参数来传递Web请求的状态）.你可能不认为在旧的J2EE平台上加入一个应用层是一种好办法。然而，你仍可以使用Seam来实现一个相同的应用层体系－区别在于，你需要架构你自己的应用并且决定需要哪些层以及它们如何协同。

Integrate JSF with EJB 3.0 将JSF和EJB3.0整合

JSF and EJB 3.0 are two of the best new features of Java EE 5. EJB3 is a brand new component model for server side business and persistence logic. Meanwhile, JSF is a great component model for the presentation tier. Unfortunately, neither component model is able to solve all problems in computing by itself. Indeed, JSF and EJB3 work best used together. But the Java EE 5 specification provides no standard way to integrate the two component models. Fortunately, the creators of both models foresaw this situation and provided standard extension points to allow extension and integration with other frameworks.

JSF和EJB3.0是Java EE 5中最好的两个特性。EJB3是一个新的服务器端的业务和持久化组件模型。同时JSF是一种很棒的表现层组件。可惜的是，这两个组件模型都没有办法单独解决所有问题。实际上，JSF和EJB3可以完美结合。但是JavaEE5规范并没有提供这两种组件模型如何整合的标准。幸运的是，这两种模型的创建者预见了这种情况并且提供了标准的扩展点，从而我们能够通过扩展来与其他框架整合。

Seam unifies the component models of JSF and EJB3, eliminating glue code, and letting the developer think about the business problem.

Seam统一了JSF和EJB3的组件模型，减少了整合代码（意思是为了让这两种模型相互沟通而必须编写的额外代码），从而能够让开发者专心于业务问题

It is possible to write Seam applications where "everything" is an EJB. This may come as a surprise if you're used to thinking of EJBs as coarse-grained, so-called "heavyweight" objects. However, version 3.0 has completely changed the nature of EJB from the point of view of the developer. An EJB is a fine-grained object—nothing more complex than an annotated JavaBean. Seam even encourages you to use session beans as JSF action listeners!

你可以写出一个完全是EJB组成的Seam应用。如果你以前认为EJB是粗粒度，重量级的家伙，你肯定会感到惊讶。实际上，EJB的3.0版本完全的改变了原始设计，从开发折角度来说，完全颠覆了旧的EJB体系。现在的EJB是一种细粒度的轻量级的对象－并不比使用注释的JavaBean复杂多少。Seam甚至鼓励你将会话Bean作为JSF动作的监听器。

On the other hand, if you prefer not to adopt EJB 3.0 at this time, you don't have to. Virtually any Java class may be a Seam component, and Seam provides all the functionality that you expect from a "lightweight" container, and more, for any component, EJB or otherwise.

          另一方面，如果你不想采用EJB3.0, 完全可以。 实际上任何Java类都可以成为Seam的组件，Seam提供了你          期望的一个轻量级容器能够提供的所有功能，并且提供了任何组件，包括EJB或其他的组件的所有功能。

Integrated AJAX 和AJAX的整合

Seam supports the best open source JSF-based AJAX solutions: JBoss RichFaces and ICEfaces. These solutions let you add AJAX capability to your user interface without the need to write any JavaScript code.

           Seam支持最棒的基于JSF的开源AJAX解决方案：JBoss RichFaces和ICEfaces. 这些解决方案能够让你根           本不用编写任何JavaScript代码的情况下，让你的用户体会到最棒的AJAX体验。

Alternatively, Seam provides a built-in JavaScript remoting layer that lets you call components asynchronously from client-side JavaScript without the need for an intermediate action layer. You can ever subscribe to server-side JMS topics and receive messages via AJAX push.

另外，Seam提供了内置的JavaScript远端层让你能够从客户端异步的调用组件，不需要通过动作层做中介。你可以随时订阅服务器端的JMS主题和通过AJAX push来接收消息。

Neither of these approaches would work well, were it not for Seam's built-in concurrency and state management, which ensures that many concurrent fine-grained, asynchronous AJAX requests are handled safely and efficiently on the server side.

          这些方法能够很好的工作完全取决于Seam内置的并发和状态管理机制，它们保证了并发的细粒度，异步                AJAX请求能够安全并且有效的在服务器端被处理。

Business process as a first class construct 一流的业务过程构建

Optionally, Seam provides transparent business process management via jBPM. You won't believe how easy it is to implement complex workflows, collaboration and and task management using jBPM and Seam.

Seam通过jBPM提供了透明的业务过程管理。你甚至不会相信通过jBPM和Seam能够这么简单的实现复杂的工作流以及协同和任务管理功能。

Seam even allows you to define presentation tier pageflow using the same language (jPDL) that jBPM uses for business process definition.

Seam甚至能够让你通过jBPM使用的业务过程定义语言(jPDL)来定义表现层的页面流。

JSF provides an incredibly rich event model for the presentation tier. Seam enhances this model by exposing jBPM's business process related events via exactly the same event handling mechanism, providing a uniform event model for Seam's uniform component model.

          JSF提供了不可思议的表现层富事件模型。通过以通用事件处理机制一样的方式暴露jBPM的业务过程相关的          事件，Seam增强了这一富事件模型，为Seam统一的组件模型提供了一种统一的事件模型。

Declarative state management 声明式的状态管理

We're all used to the concept of declarative transaction management and declarative security from the early days of EJB. EJB 3.0 even introduces declarative persistence context management.

           我们在早期的EJB中非常熟悉声明式的事务管理和安全管理的概念。EJB3.0甚至引入了声明式的持久性上           下文管理。

These are three examples of a broader problem of managing state that is associated with a particular context, while ensuring that all needed cleanup occurs when the context ends. Seam takes the concept of declarative state management much further and applies it to application state. Traditionally, J2EE applications implement state management manually, by getting and setting servlet session and request attributes.

          。。。。。。。Seam延伸了声明式状态管理的概念，提出了应用状态。传统的J2EE应用通过getting和           setting Servlet会话和请求属性来手工实现状态管理。          理

 This approach to state management is the source of many bugs and memory leaks when applications fail to clean up session attributes, or when session data associated with different workflows collides in a multi-window application. Seam has the potential to almost entirely eliminate this class of bugs.

但是通过这种方式来进行状态管理非常容易造成很多Bug和内存泄漏问题，特别是当应用程序清除会话属性失败或者和在多窗口应用中不同工作流相关联的会话数据冲突时。Seam能够完全避免这种类型的Bug.

Declarative application state management is made possible by the richness of the context model defined by Seam. Seam extends the context model defined by the servlet spec—request, session, application—with two new contexts—conversation and business process—that are more meaningful from the point of view of the business logic.

通过Seam定义的丰富的上下文模型，Seam能够进行声明式的应用状态管理。Seam扩展了Servlet规范－请求，会话，应用－加入了两个新的上下文－会话和业务过程，从业务逻辑的角度来说，这样更具意义。

You'll be amazed at how many things become easier once you start using conversations. Have you ever suffered pain dealing with lazy association fetching in an ORM solution like Hibernate or JPA? Seam's conversation-scoped persistence contexts mean you'll rarely have to see a LazyInitializationException. Have you ever had problems with the refresh button? The back button? With duplicate form submission? With propagating messages across a post-then-redirect? Seam's conversation management solves these problems without you even needing to really think about them. They're all symptoms of the broken state management architecture has been prevalent since the earliest days of the web.

Bijection 双向注射

The notion of Inversion of Control or dependency injection exists in both JSF and EJB3, as well as in numerous so-called "lightweight containers". Most of these containers emphasize injection of components that implement stateless services.

         JSF和EJB3中都存在反转控制或依赖注入的概念，其他的一些所谓“轻量级容器“也都有这些概念。大部分这         些容器都强调实现了无状态服务的组件的注入。

Even when injection of stateful components is supported (such as in JSF), it is virtually useless for handling application state because the scope of the stateful component cannot be defined with sufficient flexibility, and because components belonging to wider scopes may not be injected into components belonging to narrower scopes.

虽然有状态的组件注入被支持（例如JSF）,其实它在应用状态的处理中毫无用处，因为我们无法足够灵活的定义有状态的组件的作用范围，并且作用范围大的组件不能注入到作用范围小的组件中去。

Bijection differs from IoC in that it is dynamic, contextual, and bidirectional. You can think of it as a mechanism for aliasing contextual variables (names in the various contexts bound to the current thread) to attributes of the component. Bijection allows auto-assembly of stateful components by the container. It even allows a component to safely and easily manipulate the value of a context variable, just by assigning to an attribute of the component.

          双向注射和反转控制不同，它是动态的，具有上下文的，并且是双向的。你可以将它想象成一种组件属性的         上下文变量的别名机制（不同上下文中的名字进入到当前线程中）。双向注射能够通过容器自动组装有状态         的组件。它甚至允许一个组件仅仅通过属性赋值的方式安全并且简单的操作一个上下文变量的值。

Workspace management and multi-window browsing 工作域管理和多窗口浏览

Seam applications let the user freely switch between multiple browser tabs, each associated with a different, safely isolated, conversation. Applications may even take advantage of workspace management, allowing the user to switch between conversations (workspaces) in a single browser tab. Seam provides not only correct multi-window operation, but also multi-window-like operation in a single window!

          Seam应用能够让用户在多个浏览器窗口间切换，每个窗口和一个不同的安全隔离的对话相关联。应用甚至          利用工作域管理机制，允许用户在单一的浏览器窗口中的不同的对话（工作域）间切换。Seam不仅仅提供          正确的多窗口操作，并且在单一窗口中也能够正确处理多窗口形式的操作。

Prefer annotations to XML  使用注释，而不是XML

Traditionally, the Java community has been in a state of deep confusion about precisely what kinds of meta-information counts as configuration. J2EE and popular "lightweight" containers have provided XML-based deployment descriptors both for things which are truly configurable between different deployments of the system, and for any other kinds or declaration which can not easily be expressed in Java. Java 5 annotations changed all this.

EJB 3.0 embraces annotations and "configuration by exception" as the easiest way to provide information to the container in a declarative form. Unfortunately, JSF is still heavily dependent on verbose XML configuration files. Seam extends the annotations provided by EJB 3.0 with a set of annotations for declarative state management and declarative context demarcation. This lets you eliminate the noisy JSF managed bean declarations and reduce the required XML to just that information which truly belongs in XML (the JSF navigation rules).

Integration testing is easy 整合测试变简单了

Seam components, being plain Java classes, are by nature unit testable. But for complex applications, unit testing alone is insufficient. Integration testing has traditionally been a messy and difficult task for Java web applications. Therefore, Seam provides for testability of Seam applications as a core feature of the framework.

          Seam组件本身是普通的Java类，自然非常适合单元测试。但是对于复杂的应用来说，单元测试是不够的。

整合测试曾经是Java Web应用中非常痛苦和困难的任务。因此，Seam将整合测试作为整个应用框架中重要的核心特征。

You can easily write JUnit or TestNG tests that reproduce a whole interaction with a user, exercising all components of the system apart from the view (the JSP or Facelets page). You can run these tests directly inside your IDE, where Seam will automatically deploy EJB components using JBoss Embedded.

          你可以简单的编写JUnit或TestNG测试，模拟和用户的整个交互，剥离视图（JSP或Facelets页面）测试系统          所有的组件。你可以直接在你的IDE中运行测试，Seam使用JBoss Embedded自动将EJB组件部署。

The specs ain't perfect 规范总是不够完美

We think the latest incarnation of Java EE is great. But we know it's never going to be perfect. Where there are holes in the specifications (for example, limitations in the JSF lifecycle for GET requests), Seam fixes them. And the authors of Seam are working with the JCP expert groups to make sure those fixes make their way back into the next revision of the standards.

         我们觉得最近的Java EE规范不错。但是它远远称不上完美。规范中到处都有漏洞（例如，JSF生命周期对于         GET请求具有很大的限制），Seam矫正了这些漏洞。Seam的创建者和JCP的专家组一起工作，将在下一个         标准修订版本中矫正它们。

There's more to a web application than serving HTML pages Web应用不仅仅是HTML页面

Today's web frameworks think too small. They let you get user input off a form and into your Java objects. And then they leave you hanging. A truly complete web application framework should address problems like persistence, concurrency, asynchronicity, state management, security, email, messaging, PDF and chart generation, workflow, wikitext rendering, webservices, caching and more. Once you scratch the surface of Seam, you'll be amazed at how many problems become simpler...

当前的Web框架的视野太小。这些框架只是让你获得用户的输入，将它们传入你的Java对象。然后它们消失了。一个真正的Web应用框架应该负责解决诸如持久性，并发性，异步性，状态管理，安全，电子邮件，消息服务，PDF，图表绘制，工作流，Wiki文本绘制，Web服务，缓存和更多的问题。一旦你尝试了Seam,你会惊奇的发现这些问题非常简单...

Seam integrates JPA and Hibernate3 for persistence, the EJB Timer Service and Quartz for lightweight asychronicity, jBPM for workflow, JBoss Rules for business rules, Meldware Mail for email, Hibernate Search and Lucene for full text search, JMS for messaging and JBoss Cache for page fragment caching. Seam layers an innovative rule-based security framework over JAAS and JBoss Rules.

          Seam为持久性整合了JPA，Hibernate3，为轻量级的异步性整合了EJB Timer服务和Quartz, 为工作流整合了          jBPM, 为业务规则整合了JBoss Rules, 为电子邮件整合了 Meldware Mail, 为全文搜索整和Hibernate Search

和Lucene, 为消息服务整合了JMS,为页面片段缓存整合了JBoss Cache. Seam甚至在JAAS和JBoss Rules上增加了创新的基于规则的安全性框架。

There's even JSF tag libraries for rendering PDF, outgoing email, charts and wikitext. Seam components may be called synchronously as a Web Service, asynchronously from client-side JavaScript or Google Web Toolkit or, of course, directly from JSF.

          甚至，Seam提供了JSF标签库来绘制PDF, 电子邮件，图表和Wiki文本。Seam组件能够被Web Service同步          调用,被客户端JavaScript或者Google Web Toolkit异步调用，当然也能被JSF直接调用。

Get started now! 现在就开始！

Seam works in any Java EE application server, and even works in Tomcat. If your environment supports EJB 3.0, great! If it doesn't, no problem, you can use Seam's built-in transaction management with JPA or Hibernate3 for persistence. Or, you can deploy JBoss Embedded in Tomcat, and get full support for EJB 3.0.

          Seam可以在任何Java EE应用服务器中运行，甚至可以在Tomcat中运行。如果你的环境支持EJB3.0,那很          好！不过如果不支持，那也没关系。你可以使用Seam内置的事务管理，使用JPA或Hibernate3实现持久性。          或者，你可以将JBoss Embedded部署到Tomcat中，从而获得对EJB3.0的完全支持。