Group items tagged

@Model stereotype; it lets you give a bean a name, and set its scope to @RequestScoped in one stroke

What is the purpose of the @Model annotation?

The @Model annotation does to things: it makes the bean request-scoped (instead of dependent, the default) it gives the bean an EL name

@Inject

CDI managed beans. The @EJB annotation is removed and @Inject is used instead

Annotating the boundary (Cart) with the @Named annotation makes the Cart immediately visible for expression language (EL) expressions in JSP and JSF

@Named annotation takes the simple name of the annotated class, puts the first character in lowercase, and exposes it directly to the JSF pages (or JSP). The Cart bean can be accessed directly, without any backed or managed beans, by the JSF pages: <h:commandButton value="Check out!" action="#{cart.checkout}" />

If there is a need for abstraction, the class can be turned into an interface (or abstract class)

local implementation (with CDI events

@Inject Event<String> event;

event.fire("Order proceeded!");

remote implementation:

javax.enterprise.event.Event belongs to the CDI-implementation

class Event can be considered to be a lightweight alternative to the java.beans.PropertyChangeSupport class

@Inject Event<String> event;

event.fire("Order proceeded!");

event can be received by any managed bean and also by EJB beans

provide a method with a single @Observes annotated parameter

@Observes String event

there is no real event, just the payload:

The during attribute in the @Observes annotation allows you to select in which transactional phase the event gets delivered. The default setting is IN_PROGRESS, which causes an immediate event delivery regardless of the transaction outcome. The AFTER_SUCCESS configuration causes the delivery to occur only after successful transaction completion

Although CDI events work only inside a single process (in the default case, CDI is extensible), they are perfectly suitable for decoupling packages from modules

The method checkout() starts a transaction that gets "reused" by the OrderSystem and CustomerNotification session beans

ordering.placeOrder(); notifier.sendNotification();

EJB beans cannot be directly exposed to JSF or JSP without a little help from CDI

highly type-safe

consistent

portable

CDI enhances the Java EE programming model in two more important ways

allows you to use EJBs directly as JSF backing beans

CDI allows you to manage the scope, state, life-cycle and context for objects in a much more declarative fashion, rather than the programmatic way

CDI has no component model of its own

set of services that are consumed by Java EE components such as managed beans, Servlets and EJBs.

well-defined create/destroy life-cycle that you can get callbacks for via the @PostConstruct and @PreDestroy annotations.

Managed beans

annotation

CDI also integrates with JSF via EL bean name resolution

CDI does not directly support business component services such as transactions, security, remoting, messaging

JSR 330 defines a minimalistic API for dependency injection solutions and is primarily geared towards non-Java EE environments.

Figure 1 shows how CDI fits with the major APIs in the Java EE platform.

none of this uses string names that can be mistyped and all the code is in Java and so is checked at compile time

are additional pieces of meta-data that narrow down a particular class when more than one candidate for injection exists