深入理解Java EE 8中的CDI 2.0：自动化bean管理与事件驱动开发指南

需积分: 10 52 浏览量更新于2024-07-17 收藏 2.34MB PDF 举报

《Pro CDI 2 in Java EE 8: An In-Depth Guide to Context and Dependency Injection》是一本深度探讨Java Enterprise Edition (Java EE) 8中Context and Dependency Injection (CDI) 的专业书籍。作者Jan Beernink和Arjan Tijms在书中详尽地介绍了如何利用CDI 2.0的功能来自动管理企业级Java应用中的bean生命周期，这些bean遵循预定义的范围（Scopes）进行管理，并展示了如何通过自定义范围实现定制化的生命周期控制。在本书中，读者将了解到如何在应用程序的不同bean之间实现动态且异步的通信，这是通过CDI事件机制来实现的。CDI的核心概念包括依赖注入（Dependency Injection），即在不明确指定实现的情况下，将对象的依赖关系注入到它们的运行环境中，从而简化了组件之间的交互和管理。通过这种方式，开发人员可以专注于业务逻辑，而CDI框架负责处理对象创建、维护和销毁等生命周期管理任务。书中的内容涵盖了以下关键知识点： 1. **CDI基础**：介绍CDI的核心原则和设计理念，包括依赖注入的基本原理，以及如何在Java EE 8环境中设置和配置CDI容器。 2. **范围（Scopes）与bean生命周期管理**：讲解不同类型的范围（如Singleton、RequestScoped、SessionScoped、Dependent等），以及它们如何影响bean在应用中的生命周期和可用性。 3. **事件驱动编程**：演示如何使用CDI事件来触发异步操作，实现实时通信，提高应用的响应性和灵活性。 4. **模块化和解耦**：通过实例展示如何利用CDI来构建可扩展和模块化的应用程序架构，降低组件间的耦合度。 5. **实战案例分析**：提供实际项目的开发指南，包括如何处理复杂场景下的CDI问题，以及最佳实践分享。 6. **兼容性和迁移**：讨论Java EE 8与前版本的差异，以及如何平滑地过渡到新的CDI 2.0规范。《Pro CDI 2 in Java EE 8》是一本适合Java开发者深入理解并实践CDI技术的实用参考书籍，无论是对初学者还是经验丰富的开发人员来说，都是提升Java EE应用开发效率和质量的重要资源。通过阅读这本书，读者可以掌握如何充分利用CDI 2.0的优势，打造高效、灵活和易于维护的企业级应用。

Despite some of the unacceptable burdens that the EJB session beans put on the

developer, at their core they contained the very ideas that we still value and use today:

declarative-based services. In the early EJB 1.0 days, these consisted of fixed services for

transaction demarcation and security. For instance, using AccessControlEntry shown

earlier you could declare that the String sayHello(String name) method of a bean

was accessible only to an Identity (which was a precursor type of Principal) with, say,

the name foo.

On December 17, 1999, mere days before the turn of the millennium, Sun introduced

the EJB 1.1 specification. The most important difference was that the Java-based

deployment descriptors had been replaced by newfangled XML-based ones, and to the

detriment of developers everywhere, the deeply flawed Entity Beans were now made a

mandatory part of the EJB spec.

On June 7, 2001, during the JavaOne conference of that year, Sun senior engineers

and architects Linda DeMichiel and Ümit Yaçinalp presented the draft for EJB 2.

Included was a new SQL-based query language (EJB QL) created by Yaçinalp, two new

concepts for the security system called unchecked and uncallable (later called excluded)

methods, and, most importantly for CDI’s history, the concept of a local interface as

opposed to the existing remote interface. The local interface was seemingly a simple

concept but at the time represented a major shift in thinking. It moved away from

the thinking of an EJB bean being something like a servlet or web service and instead

allowed EJB beans to be used locally (within a single JVM), without the overhead of

serializing methods parameters and method return values and without the overhead

of going through a networking stack. With local interfaces, EJB beans could, more or

less, be used as regular classes but still with all the declarative services that EJB beans

supported.

On August 22, 2001, Sun officially released the EJB 2.0 specification, a mere five days

after another specification that plays an important role in CDI’s history had practically

started: JSF.

JSF is a component-based UI/Web MVC framework. Initially it may seem strange that

JSF would play an important role in a contextual dependency injection framework, but

in December 2001, the JSF team led by Sun engineer Amy Fowler started looking at its

very own managed bean model (aka component model). The managed bean (originally

called Object Manager) that the JSF team was working on was intended to be used for the

so-called backing bean. Backing beans are small Java classes that sit between the view

and the model. They should not be mistaken with UIComponents, which are a different

type of class altogether and are used by JSF for the visual components (aka widgets).

Chapter 1 history ofCDi

The managed bean work that started in 2001 extended into 2002, and concepts such

as scopes, names, and dependency injection were added. Specifically, scopes were a

rather novel feature of the JSF managed bean system and made these beans contextual.

Contextual here means that a “session-scoped” bean of class Foo resulted in all clients

that found themselves to be within the same HTTP session (but possibly in different

requests) getting access to the same bean instance. Clients that were in another session

got a different bean instance of Foo. Likewise, a request scope bean Bar resulted in all

clients within the same request getting the same instance of Bar, but clients in other

requests (even if, say, within the same session) getting a different instance.

The JSF team approached their component model from almost the complete

opposite direction as the EJB team did. JSF managed beans were Plain Old Java Objects

(POJOs), meaning there was no required interface that the bean had to implement and

no base class to extend from. There were also no separate interfaces to generate proxies

from, and hence there was no proxy being used whatsoever. JSF managed beans did have

to conform to the JavaBeans conventions, and like basically every other managed bean

system out there, they did have be bootstrapped by the runtime (i.e., you didn’t create

them via the new() operator but requested or got them from JSF).

Here’s an example. First you create the bean class.

public class MyServiceBean {

public String sayHello(String name) {

return "Hello, " + name;

}

Second, you make it a managed bean by declaring it into the faces-config.xml

deployment descriptor.

<!DOCTYPE faces-config PUBLIC "-//Sun Microsystems, Inc.//DTD JavaServer

Faces Config 1.0//EN"

"http://java.sun.com/dtd/web-facesconfig_1_0.dtd">

<faces-config>

<managed-bean>

<managed-bean-name>myServiceBean</managed-bean-name>

<managed-bean-scope>session</managed-bean-scope>

<managed-bean-class>test.MyServiceBean</managed-bean-class>

</managed-bean>

</faces-config>

Chapter 1 history ofCDi

The conclusion basically boils down to the advice of not using Entity Beans, ever.

Johnson did acknowledge the power of the declarative transactions and declarative

services offered by EJB session beans. In an interview with TheServerSide in early 2003,

Johnson compared these services with a limited form of AOP but suggested these should

actually be composable interceptors (à la carte) instead of the EJB approach, which was

a “degustation menu where you get everything the chef prepared whether you want it or

not.” Like King, Johnson argued the case against code generation and favored dynamic

proxies and (fast) reflection but acknowledged these things weren’t available when EJB

was initially designed. Johnson also made a strong case for using unchecked exceptions

in most cases and resorting to checked only when absolutely needed. King would later

admit to Johnson that using checked exceptions everywhere in Hibernate was a mistake

and that he would change it if he could.

On May 27, 2003, the work for EJB 3.0 started. The spec leads were Linda Demichiel

and Mike Keith. The goal of this new body of work was to radically simplify EJB by

“reducing its complexity from the EJB developer’s point of view.” The plan was to use

the recently introduced annotations in Java SE 5 to make the overly verbose deployment

descriptors fully optional and to strongly embrace the “configuration-by-exception”

approach. Session beans became POJOs (like in JSF and Spring), without interface

requirements and, unlike JSF and Spring, with only an annotation to mark them as a

session bean. Entity Beans, on the other hand, were found to be so deeply flawed at such

a fundamental level that there was no point in trying to improve them. Instead, a new

type of bean was introduced based on the simple model objects used by Hibernate and

TopLink. Spec co-lead Keith would later mention the great irony of this in his book Pro

JPA 2: “...one of the first implementations of entity beans was actually demonstrated by

adding an additional entity bean layer over TopLink mapped objects.”

AOP, as explained by Johnson, is perhaps the strongest aspect (no pun) of EJB.The

quintessential implementation of AOP at that time had always been AspectJ (and at the

time of writing still is). AspectJ, introduced in 2001, is a programming extension for Java

developed by the legendary Xerox PARC, which introduced the term aspect-oriented

programming (AOP). While arguably the most pure and powerful AOP framework out

there, AspectJ is its own language, and the very nature of it has always had a certain

academic and research feel to it. This means a level of complexity is involved with it that

makes it less suitable for enterprise developers who often don’t need the more powerful

features. Like the old EJB2, AspectJ at the time required a separate compilation step and

special IDE support.

Chapter 1 history ofCDi

剩余253页未读，继续阅读

无忧无悔无憾

粉丝: 2
资源: 58

深入理解Java EE 8中的CDI 2.0：自动化bean管理与事件驱动开发指南

Pro CDI 2 in Java EE 8

Apress.Pro.Ajax.and.Java.Frameworks.Jul.2006.HAPPY.NEW.YEAR.rar

Apress.Pro.Java.EE.Spring.Patterns.Aug.2008.rar

Apress.Pro.EJB.3.Java.Persistence.API.pdf

Apress.Pro.Ajax.and.Java.Frameworks（pdf）

Apress.Pro.Java.7.NIO.2.2011

Apress.Pro.EJB.3.Java.Persistence.API

Apress.Pro.Silverlight.2.in.C#.2008.Nov.2008.PDF

Apress.Pro.XML.Development.with.Java.Technology

Apress.Pro.Java.6.3D.Game.Development.Java.3D.JOGL.JInput.and.JOAL.APIs.Apr.2007

最新资源