Group items tagged

Stateless beans must have a dependent scope while a stateful session bean can have any scope. By default they are transactional, but you can use the transaction attribute annotation.

CDI beans can be injected into EJBs and EJBs can be injected into CDI beans

When to use which bean How do you know when to use which bean? Simple.

In general, you should use CDI beans unless you need the advanced functionality available in the EJBs such as transactional functions. You can write your own interceptor to make CDI beans transactional, but for now, its simpler to use an EJB until CDI gets transactional CDI beans which is just around the corner

Comparing JSF Beans, CDI Beans and EJBs

JSF Managed Beans

In short, don’t use them if you are developing for Java EE 6 and using CDI. They provide a simple mechanism for dependency injection and defining backing beans for web pages, but they are far less powerful than CDI beans.

JSF beans cannot be mixed with other kinds of beans without some kind of manual coding.

CDI Beans

includes a complete, comprehensive managed bean facility

interceptors, conversation scope, Events, type safe injection, decorators, stereotypes and producer methods

JSF-like features, you can define the scope of the CDI bean using one of the scopes defined in the javax.enterprise.context package (namely, request, conversation, session and application scopes). If you want to use the CDI bean from a JSF page, you can give it a name using the javax.inject.Named annotation

Comparing JSF Beans, CDI Beans and EJBs

Comparing JSF Beans, CDI Beans and EJBs

JSF Managed Beans

@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

bean-validation JPA, Bean Validation Shows how to use Arquillian to test Bean Validation

ejb-security Security, EJB Shows how to use Java EE Declarative Security to Control Access to EJB 3

payment-cdi-event CDI Demonstrates how to use CDI 1.0 Events

richfaces-validation RichFaces Demonstrates RichFaces and bean validation

ejb-in-war JSF, WAR, EJB Packages an EJB JAR in a WAR

greeter EJB, JPA, JSF, JTA, CDI Demonstrates the use of CDI 1.0, JPA 2.0, JTA 1.1, EJB 3.1 and JSF 2.0

helloworld-mdb EJB, MDB, JMS Demonstrates the use of JMS 1.1 and EJB 3.1 Message-Driven Bean

helloworld-rs JAX-RS, CDI Demonstrates the use of CDI 1.0 and JAX-RS

kitchensink BV, EJB, JAX-RS, JPA, JPA, JSF, CDI

servlet-async CDI, EJB, Servlet Demonstrates CDI, plus asynchronous Servlets and EJBs

servlet-security Security, Servlet Demonstrates how to use Java EE declarative security to control access to Servlet 3

shopping-cart EJB Demonstrates a stateful session bean

tasks Arquillian, JPA Demonstrates testing JPA using Arquillian

GraniteDS validation framework provides a set of standard constraints

Constraint Description AssertFalse The annotated element must be false AssertTrue The annotated element must be true DecimalMax The annotated element must be a number whose value must be lower or equal to the specified maximum DecimalMin The annotated element must be a number whose value must be greater or equal to the specified minimum Digits The annotated element must be a number whithin accepted range Future The annotated element must be a date in the future Max The annotated element must be a number whose value must be lower or equal to the specified maximum Min The annotated element must be a number whose value must be greater or equal to the specified minimum NotNull The annotated element must not be null Null The annotated element must be null Past The annotated element must be a date in the past Pattern The annotated String must match the supplied regular expression Size The annotated element size must be between the specified boundaries (included)

must use

Note that the bundle name must always be set to "ValidationMessages".

JSR-303 (“Bean Validation”) ActionScript3 framework for form validation

validation framework is a specific adaptation of the JSR-303 (Bean Validation) specification to Flex: like its Java counterpart, it relies on validation annotations placed on bean properties and provides an engine API that lets you validate your forms without writing by hand a specific validator for each of your input fields

code generation tools provided by GraniteDS so that when you write your Java entity bean with validation annotations, they are automatically replicated in your ActionScript3 beans

problem with LCDS is mainly that it promotes a strict “client / server” architecture, with – roughly speaking – a heavy Flex client application connected to a server almost reduced to a database frontend

big majority of  these organizations use BlazeDS, a free and open-source subset of LCDS

need more advanced mechanisms than just Remoting start looking for open-source libraries to enable deeper integrations with the Java business layer, and GraniteDS is for sure the most popular project

“Flex Data Services” (now renamed to “Live Cycle Data Services”)

Flex Data Services seemed too “client-centric”

for GraniteDS users keeping their Java domain model and ActionScript3 domain model in sync via Gas3, the constraints are kept in sync

a couple of gotchas to be aware of

the constraint implementation is in the same class as the constraint declaration (not a problem in a dynamic language) @Pattern has a sightly different semantic because the regexp engine in Flex is a bit different. instead of the features provided by ConstraintValidatorContext, you can define a properties attribute in your constraints to make it belong to several sub-properties. not as flexible but good enough in many cases.

must declare your classes in separated source files if you want them to be correctly handled by the generator

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

Anti-Pattern

Use Stateful Session Beans

eager load the relations

@Size(min = 3, max = 80)

@NotNull

LastName

extend AbstractBuilder

must implement the buildInternal() method:

Builder extends AbstractBuilder<Customer>

@Override protected Customer buildInternal()

Implementing the Builder Pattern using the Bean Validation API

variation of the Builder design pattern for instantiating objects with multiple optional attributes.

this pattern frees you from providing multiple constructors with the different optional attributes as parameters (hard to maintain and hard to read for clients)

or providing setter methods for the optional attributes

In general, JDBC Templates are a poor solution. They don’t have enough abstraction to work on different databases because you use plain SQL in queries. There is also no real ORM mapping which results in quite a lot of boilerplate code

SimpleJdbcTemplate(ds)

@InterceptorBinding

@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

always have to include this library in either WEB-INF/lib

support for CDI is included in the library granite-cdi.jar

10.1. Configuration with Servlet 3 On Servlet 3 compliant containers, GraniteDS can use the new APIs to automatically register its own servlets and filters and thus does not need any particular configuration in web.xml. This automatic setup is triggered when GraniteDS finds a class annotated with @FlexFilter in one of the application archives:

@FlexFilter(configProvider=CDIConfigProvider.class) public class GraniteConfig { }  

list of annotation names that enable remote access to CDI beans

@FlexFilter declaration will setup an AMF processor for the specified url pattern

@TideEnabled

@RemoteDestination

always declared by default

10.3.2. Typesafe Remoting with Dependency Injection

It is possible to benefit from even more type safety by using the annotation [Inject] instead of In. When using this annotation, the full class name is used to find the target bean in the CDI context instead of the bean name.

Security

integration between the client RemoteObject credentials and the server-side container security

client-side component named

API to define runtime authorization checks on the Flex UI

bindable property

represents the current authentication state

integrated with server-side role-based security

clear the security cache manually with

injected managed beans (controls) results in the simplest possible architecture

Due to the limited capabilities of the ActionScript 3 reflection API than cannot access private fields, it is necessary to create an externalizable AS3 class (implementing flash.utils.IExternalizable and its corresponding externalizable Java class

In both classes you have to implement two methods

the Gas3 generator can automatically generate the writeExternal and readExternal methods.

With GraniteDS automated externalization and without any modification made to our bean, we may serialize all properties of the Person class, private or not

In order to externalize the Person.java entity bean, we must tell GraniteDS which classes we want to externalize with a

externalize all classes named com.myapp.entity.Person by using the org.granite.hibernate.HibernateExternalizer

you could use this declaration, but note that type in the example above is replaced by

            <include annotated-with="javax.persistence.Entity"/>             <include annotated-with="javax.persistence.MappedSuperclass"/>             <include annotated-with="javax.persistence.Embeddable"/>

: type

annotated-with

Instead of configuring externalizers with the above method, you may use the

feature:

precedence rules for these three configuration options: