Please respect the results, if you need to reprint, please indicate the source http://equalxx.iteye.com/
Chapter 2.More about beans
Beans are generally application classes that contain business logic. Can be called directly by java code, or in standard EL expressions. Beans can also access transactional resources. Dependencies between beans are automatically managed by the container, and most beans are stateful and contextual. The lifecycle of beans is managed by the container.
Let's look again, what exactly is "contextual"? Whether a bean has state or not depends on which instance of the bean I have. Unlike a stateless component model (such as stateless session beans ) or a singleton component model (such as servlets or singleton beans ), stateful beans have different states on different clients. Whether or not to identify the user-visible state ( client-visible state ) depends on whether the client has a reference to an instance of this bean .
Stateless or singleton model, unlike a stateful session bean , the client does not control its lifecycle by explicitly creating and destroying it. Instead, use the bean scope to decide:
1. The life cycle of each bean instance
2. Which clients can share a reference to a specified instance of the bean
For a given thread of a CDI application, there may be an activity context associated through the bean scope . This context may be unique within this thread (e.g. the bean is request scoped ), or it may be shared with other threads at the same time (e.g. the bean is session scoped ), or even shared with all other threads (this uses is application scoped ).
Clients executing in the same context (such as other beans ) use the same bean instance. But clients executing in different contexts use different instances (depending on the relationship between the contexts).
One of the biggest advantages of contexts is that they allow state beans to act like services . The client does not have to manage the life cycle of its bean , nor does it need to know what the life cycle of the bean is. These beans are loosely coupled because:
1. They manage their relationship with each other through an explicit public API
2. Their life cycle is completely decoupled from the client
We can replace a bean with another bean that inherits the same interface (this bean can have a different life cycle ( scope )) without affecting the implementation of any other bean . In fact, CDI provides an easy way to reload at deployment time, which we'll cover in detail in Section 4.7 , " Alternatives ".
要注意不是所有bean的客户端都是bean本身。其他对象，比如servlets或消息驱动bean（message-driven beans），他们都不是可注入到其他bean的上下文对象，但他们仍然能够通过注入获取对其他bean的引用。
2.1. The anatomy of a bean 对bean的解析
在此前我们已经铺垫了这么多，下面我们来正式地介绍bean，根据规范：
一个bean由以下属性组成：
1、一个（非空）bean类型集
2、一个（非空）限定符集
3、一个Scope
4、可选，一个bean EL name
5、一组拦截器绑定
6、一个bean的实现
此外，一个bean可能是alternativ的，也可能不是。
让我们去看看这些属性都是什么意思。
2.1.1 Bean types，qualifiers and dependency injection bean类型，限定符和依赖注入
Bean通常通过依赖注入获取对其他bean的引用。任何一个被注入的属性规定了一个“合同”，所有要注入的bean必须满足这个“合同”。这个“合同”就是：
1、bean type
2、一组限定符
bean type表明了bean是用户可见类型，它可以是用户定义的class或接口。如果bean是个EJB会话bean，那么它的bean type就是@Local接口，或是bean-class的本地视图。一个bean可能会有很多个bean type。比如说下面的bean有四个bean type：
public class BookShop
extends Business
implements Shop<Book> {
...
}
它的bean type是 BookShop，Business和Shop<Book>，以及隐式类型java.lang.Object。（注意，参数化类型是合法的bean类型）。
同时，下面这个会话bean只有本地的三个接口BookShop，Auditable和java.lang.Object可以作为bean type，但由于@Stateful，BookShopBean不是用户可见类型。
@Stateful
public class BookShopBean
extends Business
implements BookShop, Auditable {
...
}
注意：会话bean的bean type包括本地接口和bean类local view（如果有的话）。EJB远程接口不被认为是会话bean的bean type。你不能把一个EJB通过远程接口注入，除非你定义一个资源，这个会在Chapter 14，Java EE组件环境资源中介绍。
（译者注：其实这段光看英文感觉难以和实际使用关联起来，bean type到底讲了什么，查看了一些资料以后我认为可能是在说，bean通过可以通过不同的bean type注入，而bean type包含了什么内容，有个网址里面有说明http://moon26.blogspot.jp/2012/01/javaee6-cdi-bean-and-bean-types.html，我会接下来和同事一起讨论，它究竟在开发中处于什么角色，再来更新此部分内容）
Bean types可以通过@Typed注解来指定，同时列出所有应该为bean type的类。比如说这个bean types bean已经被限制为Shop<Book>和java.lang.Object：
@Typed(Shop.class)
public class BookShop
extends Business
implements Shop<Book> {
...
}
有时，仅有bean type的话并不能提供给容器足够的信息去让容器知道该注入哪个bean。举例说，假设我有两个实现了PaymentProcessor接口的实现类：CreditCardPaymentProcessor和DebitPaymentProcessor。如果把它俩注入到PaymentProcessor类型的域中，就会引起混淆。在这种情况下，用户必须提供更多的特性来告知容器应该注入哪一个。所以我们通过qualifier来指明特性。
一个qualifier是个用户定义的注解，用@Qualifier来定义。它是一个类型系统（type system）的一个扩展。它使我们不用基于名称来区分注入类型。以下就是个用@Qualifier注解的例子：
@Qualifier
@Target({TYPE, METHOD, PARAMETER, FIELD})
@Retention(RUNTIME)
public @interface CreditCard {}
你可能还不习惯看到上面这样的创建注解的代码，有可能这是你第一次遇到这样定义。用CDI的话，定义注解将会成为你时不时需要去做的事儿。
注意：
请注意在CDI和EJB中的注解名称，你会发现他们多是形容词。我们鼓励您在创建自定义注解时候也遵循这种习惯，当它们是用来描述行为和指明类角色的时候。
现在我们已经定义了一个特性注解了，我们可以在注入点使用它来明确注入类。下面的注入点包含了bean类型PaymentProcessor以及qualifier @CreditCard：
@Inject @CreditCard PaymentProcessor paymentProcessor
注意：
若一个bean或是一个注入点没有被一个qualifier修饰，它会有一个默认修饰符@Default。
这还没结束，CDI还定义了一个简单的解决规则用来帮助容器该接下来怎么做，当多个bean同时满足“合同”的时候。我们会在Chapter 4，依赖注入和程序化查找章节讨论细节。
请尊重成果，如需转载请注明来源http://equalxx.iteye.com/