Please respect the results, if you need to reprint, please indicate the source http://equalxx.iteye.com/
Off-topic: Ah = = It's been a long time since I updated. I have been working before and spent a busy Spring Festival. My beloved grandpa completed his 82-year journey this year. Sometimes I really need to think about the meaning of life. After coming to this company, my weight has increased by more than ten pounds, and I have changed from a girl to an aunt. . I warn everyone to eat less takeout, and don’t always think that licking the plate is a waste of food. It’s healthier to eat less. Exercise more, yes, exercise more.
2.1.2 Scope
A bean 's Scope determines the lifetime and visibility of its instances. The CDI context model is extensible and can be used to accommodate multiple scopes . Some important scopes are built into the specification and provided by the container. Each scope has an annotation modifier. For example, any web application is likely to have session scoped beans :
public @SessionScoped
class ShoppingCart implements Serializable { ... }
A bean decorated with session scoped will be bound to the user session ( user session ) and shared by all requests executed in the context of this session.
Notice:
Note that once a bean is bound to a context, it remains in the context until the context is destroyed. There isn't any manual way to remove a bean from the context . If you don't want the bean to stay in the session, consider using a shorter-lived scope , like a request or conversation scope .
If no scope is specified explicitly , the bean will belong to a special scope called the dependent pseudo- scope . Beans belonging to this scope will only live and serve objects injected in themselves, which means that their lifetime depends on the lifetime of the injected object.
We'll talk more about scopes in Chapter 5 scopes and contexts .
2.1.3. EL name
If you want to reference the bean in non- Java code that supports EL expressions (such as JSP or JSF ), you must add an EL name to the bean .
EL names are defined by the @Named annotation as follows:
public @SessionScoped @Named("cart")
class ShoppingCart implements Serializable { ... }
Now I can easily use it in JSF or JSP pages:
<h:dataTable value="#{cart.lineItems}" var="item">
...
</h:dataTable>
Notice:
The @Named annotation is not used to specify whether the class is a bean or not . Most classes are already recognized as beans . This @Named annotation is only used for EL reference beans , the most common is the invocation of JSF views.
Instead of writing the name in parentheses after Named , we can let CDI specify a name by itself, like this:
public @SessionScoped @Named
class ShoppingCart implements Serializable { ... }
The default name is an unqualified class name with a lowercase first letter, which is shoppingCart in the above example .
2.1.4 Alternatives
We have already seen how to use qualifiers to distinguish different implementations of the same interface during the development phase. But some interfaces (or other bean types ) their implementation needs to depend on the development environment. For example, we may need to use a mock implementation (different from the real application scenario implementation) during the testing phase. In this case, you can use the @Alternative annotation on the class.
public @Alternative
class MockPaymentProcessor extends PaymentProcessorImpl { ... }
We usually add the @Alternative annotation to the implementation class when there are other implementation classes for the same interface . We can configure different alternative implementations in the META-INF/beans.xml of the jar package or Java EE module during the deployment phase . Different alternatives are used in different deployment scenarios.
We will explain further in Section 4.7 Alternatives .
2.1.5 Interceptor binding types
You should be familiar with using interceptors in EJB 3 . Since JavaEE 6 , this functionality has been available to other managed beans . That is, there is no need to create an ejb for an intercepting method anymore. So what can CDI provide on top of this? There are many, so let's start with a little background.
在JavaEE 5中设计的拦截器是有点不科学的。会要求开发者直接在EJB的实现中通过@Interceptors注解或xml配置去实现拦截器。这样造成用户可能直接把拦截器代码放到实现类里了。第二，拦截器调用顺序取决于注解或xml描述中的声明顺序。可能这种方式对于单个bean还不算太糟糕。但是如果你反复使用拦截器，会发生对不同的bean有着不同的拦截器调用顺序。问题就来了。
CDI提供了间接层来把拦截器和bean绑定，并进行控制。我们必须定义一种绑定类型来描述一个拦截器的实现。
拦截器绑定类型是由用户通过@InterceptorBinding定义的注解。它可以使拦截器类简洁且无直接依赖地绑定到bean类上。
@InterceptorBinding
@Inherited
@Target( { TYPE, METHOD })
@Retention(RUNTIME)
public @interface Transactional {}
实现了事务管理的拦截器可以像下面这样声明：
public @Transactional @Interceptor
class TransactionInterceptor { ... }
我们可以通过在bean class上标注拦截器绑定类型来实现bean上的拦截：
public @SessionScoped @Transactional
class ShoppingCart implements Serializable { ... }
请注意ShoppingCart和TransactionInterceptor之间没有任何联系。
拦截器是部署时指定的。（我们在单元测试时不需要拦截器！）一个拦截器默认为不可用的。我们可以通过jar包或是Java EE 模块的CDI部署描述文件META-INF/bean.xml来使一个拦截器可用，这些文件也可以定义拦截器顺序。
我们会在Chapter 9 拦截器以及Chapter 10装饰器中讨论拦截器，以及它的兄弟装饰器。
请尊重成果，如需转载请注明来源http://equalxx.iteye.com/