Extending Java EE with CDI and JBoss Forge

Extend Java EE with CDI
Antoine Sabot-Durand · Antonio Goncalves

Antoine Sabot-Durand
 Red Hat
 CDI spec lead
 @antoine_sd
 next-presso.com
 github.com/antoinesd

Antonio Goncalves
 Java Champion
 Contractor developper
 antoniogoncalves.org
 @agoncal
 github.com/agoncal

Agenda
 Meet ExpensEEs
 Meet CDI
 Basic DI
 Producers
 Interceptors
 Qualifiers
 Programmatic Lookup
 Contexts
 Events
 Extensions
 Conclusion

Expenses made EEsy
Meet ExpensEEs

We were asked to build this app
 A web app to manage expenses
 Based on Java EE 7
 CDI 1.2
 JPA 2.1
 JSF 2.2
 JAX-RS 2.0
 Able to integrate legacy libs

Architecture - Model
User
String login
String password
String name
String email
UserRole role
Reimbursement
Date date
Set<Expense> expenses
Currency currency
User user
Conference conference
Expense
description
Date date
Float amount
ExpenseType expenseType
private Currency currency
Conference
String name
Date date
String country
String city
1
*
1 *
1
*

JBoss Forge
Forge
1. Generation & Scaffolding tool
2. Shell commands & IDE Integration
3. Gets you start quickly
4. Takes care of integration
5. Plugin based
6. Java EE… But anything else really
7. More info on forge.jboss.org/

Back to demo
 Run JBoss Forge
 Create JPA Entities
 Scaffold JSF CRUD pages
 Scaffold REST Endpoint
 Run Forge script

Architecture Forge
html
web rest
model
ConferenceCRUDExpenseCRUD ReimbursementCRUD UserCRUD
ConferenceBeanExpenseBean ReimbursementBean UserBean ConferenceEndpoint
ConferenceExpenseService Reimbursement User
useuse use use
useuseuse use use

Not Finished Yet
1. Only a CRUD app
2. No "Create expenses" Wizard
3. No Login/logout
4. Primefaces
5. Java EE 6 instead of Java EE 7
6. JTA 1.2 @Transactional
7. JPA 2.1 Insert data in DB
8. Not in full CDI programming model !

Back to demo
 Refactor the app
 Add a service layer
 Add Java EE 7 dependencies
 Less EJB More CDI
 Webjar for Twitter Bootstrap
 2 hours later…

New Architecture
html
web rest
service
model
ConferenceCRUDExpenseCRUD ReimbursementCRUD UserCRUD
ConferenceBeanExpenseBean ReimbursementBean UserBean ConferenceEndpoint
ConferenceServiceExpenseService ReimbursementService UserService
ConferenceExpense Reimbursement User
useuse use use
@Inject@Inject@Inject @Inject @Inject
useuse use use

Contexts and Dependency Injection
Meet CDI

What is CDI?
 A Java EE spec.
 ASL2 (even TCK)
 Launched in Java EE
6
 2 releases since launch
 1.2 is last (Java EE 7)
 2.0 on its way
 2 major impl.
 JBoss Weld (RI)

What’s included?
CDI Provides:
1. A powerful programming model
2. Different Lifecycles for stateful
objects
3. A Typesafe DI mechanism
4. The ability to decorate injected
objects
5. The ability to intercept methods
6. An event notification model
7. A SPI allowing portable extensions to integrate 3rd party tech

“
CDI explained to your boss
CDI brings a powerful and modern programming
model that standardizes good practices.
CDI provides a consistent and seamless way to
integrate 3rd party frameworks to this model.
Once adopted, CDI will become the invisible
backbone of our projects.

“
One container to rule them all
 The container is the heart of CDI
 The container checks all possible CDI code at boot time
 The container manages your components lifecycle and services
 Yet, you’ll never see it (except in advanced development)
Container is your application’s invisible conductor

Almost Everything is a bean
 During boot time, the container scans each class to check if it
meets the conditions to be a bean
 These conditions are very loose so, most pojo classes are beans
public class HelloService {
public String hello() {
return "Hello World!";
}
}
HelloService is a concrete class with a default constructor, therefore it’s a bean
1
1

Injection in bean field
 A bean can inject other beans or be injected into other beans
public class MyBean {
@Inject
private HelloService service;
public void displayHello() {
display(service.hello();
}
}
@Inject annotation defines an injection point (here a field)
The container looksa for the bean to inject by its type (here HelloService )
1
2
1
2

Injection in bean constructor
 To become a bean a class must have a constructor with no
parameters or a constructor annotated @Inject
@Inject
private MyBean(HelloService service) {
this.service = service;
}
}
 Only one constructor can be annotated with @Inject

Injection in a method
 Such method is called initializer methods
@Inject
public void initService(HelloService service) {
this.service = service;
}
}
 all initializer methods are called at bean instantiation

There could be only one
 Each injection point is checked at boot time:
 If no bean is eligible for it, the injection point is unsatisfied

If multiple beans are eligible for it, the injection point is
ambiguous
 In both case a DeploymentException is thrown by the container

Back to demo
 Inject a Logger into UserService
 Log a message in persist method

When you don’t own your bean’s class, use
Producers

What is a producer?
 A way to declare a bean…
 …from a field or a method…
 …for a class you don’t own…
 …or a non CDI class.

Declaring a Producer
public class ProducingBean {
@Produces
private List<Integer> mapInt = new ArrayList<>();
@Produces
@French
public List<String> FrenchListStrProducer() {
List<String> res = Arrays.asList("bonjour");
return res;
}
}
Producers should be declared in a Bean class
It’s a field or a method annotated with @Produces (static methods supported)
Producers can have qualifiers
value of field or method returned value is the bean instance
1
2
2
3
4
1
2
3
4

Producers are an other kind of bean
 they can have qualifiers like any other bean
 producer method (or field) is called to create the bean instance
@Inject
@French
private List<String> frenchListStrBean;
@Inject
public MyBean(List<Integer> initValues) {
...
}
}

Disposers are Producer’s housekeeping
 Disposers can free resources when produced bean is destroyed
@Produces
public MyNonCDIClass myProducer() {
return new MyNonCdiClass();
}
public void releaseMyInstance(@Disposes MyNonCdiClass inst) {
inst.clean();
}
}
Will be called at the bean instance end of life
1
1

Producer methods can have parameters
 Parameters will be injected by the container at instantiation time
 They should have matching beans otherwise deployment fails
@Produces
public MyNonCDIClass listStrProducer(MyBean bean) {
...
}
}
The container resolves MyBean and passes it to the producer when an instance of the bean is requested
1
1

Back to demo
 The class LoggerProducer produces a Logger
 Injecting a logger in service doesn’t change

Accessing Injection Point metadata
 The container can provide metadata about the Injection Point
@Produces
public Logger produceLog(InjectionPoint injectionPoint) {
return Logger.getLogger(injectionPoint.getMember()
.getDeclaringClass().getName());
}
}
InjectionPoint is a SPI interface. The container can inject it to give info about the injection point
1
1

Back to demo
 Add InjectionPoint API to the producer
 Injecting a logger in service doesn’t change

Interceptors vs Decorators
 They are both Aspect Oriented Programming tools
 Interceptors are technical oriented: transaction, security, logging
 Interceptors are bound to any bean or bean method
 Decorators are business oriented: change the behaviour of a bean
 Decorators are bound to a bean type

Interceptors
 Interceptors are defined in their own specification
 User should create an annotation as an interceptor binding
 Interceptor class must be bound to an interceptor binding
 Interceptor class contains intercepting methods
which are bound to lifecycle phase of intercepted bean
 Interceptor binding is added to intercepted bean or method

Interceptor binding example
 An interceptor binding is annotation used in two different places
 On the interceptor and on the intercepted element to link them
@InterceptorBinding
@Target({METHOD, TYPE})
@Retention(RUNTIME)
public @interface Loggable {}
This annotation comes from interceptor specification. It makes @Loggable an interceptor binding
1
1

Interceptor example
@Interceptor
@Loggable
@Priority(Interceptor.Priority.APPLICATION)
public class LogInterceptor {
@AroundInvoke
public Object log(InvocationContext ic) throws Exception {
System.out.println("Entering " + ic.getMethod().getName());
try {
return ic.proceed();
} finally {
System.out.println("Exiting " + ic.getMethod().getName());
}
}
}
We make the class an interceptor ( @Interceptor comes from Interceptor spec)
We bind this interceptor to the @Loggable interceptor binding
We activate and give a priority to the interceptor (can be done in beans.xml config file as well)
This intercepting method will be invoked instead of the intercepted one.
1
2
3
4
1
2
3
4

Interceptor Usage
@Loggable
public class MyBean { ... }
public class MyOtherBean {
@Loggable
public String hello() { ... }
}
All bean’s method will be intercepted
This method will be intercepted
1
2
1
2

Decorators
 To be decorated, a bean should implement an interface
 The decorator has to implement the same interface
 It is declared with @Decorator annotation
 It can be an abstract class (lets you choose methods to decorate)
 It injects the decorated bean with @Delegate annotation

Decorator Example
@Decorator
public abstract class HelloDecorator implements HelloService {
@Inject @Delegate HelloService service;
return service.hello() + "-decorated";
}
}
Declares that the class is a decorator
Activates and gives a priority to the decorator (could be done via beans.xml file)
Decorators can be abstract and should share the same interface than decorated beans
Decorated bean is annotated with @Delegate (other beans could be injected in decorator)
Decorating method is called instead of decorated bean method. Delegate can be used in it.
1
2
3
4
5
1
2
3
4
5

Back to demo Create a @Loggable interceptor binding
 Create a LoggingInterceptor
 Add LoggingInterceptor to each service
 Enable interceptor in the beans.xml

Solving ambiguous cases with
Qualifiers

When an injection point resolves to multiple beans…
@Inject
HelloService service;
}
public interface HelloService {
public String hello();
}
public class FrenchHelloService implements HelloService {
return "Bonjour tout le monde!";
}
}
public class EnglishHelloService implements HelloService {
}
}
 deployment fails with an Ambiguous dependencies error.

The solution is to create Qualifiers…
@Qualifier
@Retention(RUNTIME)
@Target({FIELD, TYPE, METHOD, PARAMETER})
public @interface French {
}
@Qualifier
@Retention(RUNTIME)
public @interface English {
}
 Qualifiers are annotations annotated with @Qualifier

to qualify beans sharing the same
type…
@French
}
}
@English
}
}

and distinguish them at injection
points.
@Inject
@French
HelloService serviceFr;
@Inject
@English
HelloService serviceEn;
}
 Qualifiers are types enhancing injection, yet keeping it strong
typed

Qualifiers can have members
@Qualifier
@Retention(RUNTIME)
public @interface Language {
LangChoice value();
@Nonbinding
String description() default "";
public enum LangChoice {
FRENCH, ENGLISH
}
}
@Nonbinding member’s value isn’t used in bean resolution mechanism
1
1

Binding members limit the number of annotations to add to your
code
@Language(FRENCH)
}
}
@Language(ENGLISH)
}
}
@Inject
@Language(value = FRENCH, description = "ici on parle français")
@Inject
@Language(value = ENGLISH, description = "english spoken here")
HelloService serviceEn;
}

Multiple qualifiers
 A bean can have multiple qualifiers
@Language(FRENCH) @Console
}
}
@Inject
}
@Console is a qualifier
1
1

Multiple qualifiers
 Injection point can have a non empty subset of the bean’s
qualifiers
}
}
@Inject
@Console
}

Multiple qualifiers
 Injection point can’t have a super set of bean’s qualifier
}
}
@Inject
@Language(FRENCH) @Console @Language(CANADIAN)
}
Unsatisfied injection point: deployment fails
1
1

Built-in qualifiers
 @Named set bean name for weak typed environment (EL,
Javascript)

@Default added to beans without qualifier or having only
@Named
 @Any added to all beans for programmatic lookup and decorators

@Intercepted & @Decorated to inject intercepted bean in an
interceptor / Decorator
 @Initialized to qualify events when a context is started

Examples
public class MyBean { ... }
@Named
public class MyBean2 { ... }
@Named @Language(FRENCH)
public class MyBean2 {
@Inject
MyBean2 bean;
}
this bean has @Default and @Any qualifiers
this bean has @Default , @Named and @Any qualifiers
this bean has @Language(FRENCH) , @Named and @Any qualifiers
this injection point has @Default qualifier
1
2
3
4
1
2
3
4

Bean Types
 A bean has a set of types depending on its definition

Bean types set for a managed bean contains the bean class, every
superclass and all interfaces it implements directly or indirectly.
 Bean types can be restricted by using @Typed annotation ( Object
is always in the set)

Bean types Example
public interface HelloService extends Hello { ... }
@Produces
public HelloService prodHelloService() { ... }
}
  public class FrHelloService extends GenericService<String> implements HelloService { ... }
  @Typed({HelloService.class})
 public class FrHelloService extends GenericService<String> implements HelloService { ... }
class MyBean and Object
HelloService , Hello and Object
FrHelloService , GenericService<String> , HelloService , Hello and Object
HelloService and Object
1
2
3
4
1
2
3
4

Parameterized types count
 Parameterized types information is kept (i.e. no type erasure)
@Inject
Service<User> userService;
@Inject
Service<Staff> staffService;
}
 Injection points above can be satisfied without ambiguity

Performing Typesafe Resolution
 When resolving a bean to be injected to an injection point…
 …the container considers bean type and qualifiers.
 If the bean has a bean type that matches injection point type…
 …and the bean has all the qualifiers of the injection point…
 …the bean is assignable to the injection point.

Back to demo Create a @Clear and @Encrypted qualifiers
 Create a DigestPassword interface
 Two implementations ClearPassword and EncryptPassword

Inject encrypted password digest into AccountBean and
UserService

Resolving beans at runtime
Programmatic Lookup

Meet Instance interface
 Instance interface lets perform typesafe resolution at runtime
@Inject
Instance<HelloService> service;
display(service.get().hello());
}
}
Instance<T> injection points are always satisfied and never fail at deployment time
with Instance<T> you control when bean a instance is requested with the get() method
1
2
1
2

Check bean existence at runtime
 Instance<T> contains methods to test bean resolution
@Inject
Instance<HelloService> service;
if (!(service.isUnsatisfied() || service.isAmbiguous())) {
display(service.get().hello());
}
}
}
if tou skip the test get() may throw an exception
1
1

Looping on all beans in the Instance
 Instance<T> is iterable
 It’s where we use the @Any qualifier present on all beans
@Inject
@Any
Instance<HelloService> services;
for (HelloService service : services) {
display(service.hello());
}
}
}

Select a bean by its qualifier
 AnnotationLiteral is a helper class to create an annotation instance
@Inject
@Any
Instance<HelloService> services;
display(
services.select(new AnnotationLiteral()<French> {}).get());
}
}
select() also accepts a type.
 you can use TypeLiteral to create instances of parameterized types
1
1

Back to demo
 Loop through all DigestPassword
 Thanks to @Any
 Use either @Encrypted or @Clear

Bean, Scope and Contexts
 All Beans have a scope defined by an annotation
 Each scope is associated to a context object
 So each bean is bound to a context
 The context is in charge of creating bean instances
 The Container is in charge of creating and destroying contexts

Available scopes
 CDI provides the following built-in scopes (and associated contexts):
 @Dependent (default) bean has the same scope than its injector
 @ApplicationScoped instance is linked to application lifecycle
 @SessionScoped instance is linked to http session lifecycle
 @RequestScoped instance is liked to http request lifecycle
 @ConversationScoped lifecycle manually controlled within session

Instance is created at first request and destroyed with its bound
context
 CDI SPI allows third party to create their custom contexts

Examples
public class BaseHelloService implements HelloService { ... }
@RequestScoped
public class RequestService {
@Inject HelloService service;
}
@ApplicationScoped
public class ApplicationService {
@Inject RequestService service;
}
Bean has default scope @Dependent , instances are created for each injection
Bean is @RequestScoped . Instance is created by request context and destroyed with request context
Bean is @ApplicationScoped . Instance is created by application context and will live during all
application
No problem to inject bean from an other scope: CDI will provide the right bean
1
2
3
4
1
2
3
4

Good to know
 instances are created when first accessed not with their context
 A bean instance is a singleton in its context
 With SPI you can manually destroy an instance in a context
 A context can be inactive without being destroyed
 Request context is more than a mapping to ServletRequest lifecycle

More on @ConversationScoped
 A context whose lifecycle is controlled by the dev
 Conversation is transient or long running
 It’s promoted to long running with Conversation built-in bean…
 … by calling begin() method…
 … and terminated with end() .
 There can be multiple conversations in one Http Session
 Conversation id is used to retrieve the active conversation

Example
@ConversationScoped
public class WizardBean {
@Inject
Conversation conversation;
public startWizard() {
...
conversation.begin()
...
}
public endWizard() {
...
conversation.end()
...
}
}

Back to demo
 Wizard to create new expenses
 Use of @ConversationScoped
 JSF deals with cid

Contexts are not always convenient
 Lifecycle magic management can limit you
 Bean instances are destroyed only when context ends
 And you might want to get rid of instance but keep the context
 CDI 1.1 added a programmatic way to destroy an instance

Example - Logout and session invalidation
@Inject FacesContext facesContext;
public String logout(){
try{
facesContext.getExternalContext().invalidateSession();
return "success?faces-redirect=true";
}
catch(Exception e){
return "error";
}
}
redirect is important to end current request and kill the session effectively
 we might want to keep the current session and logout user
 not a good practice to call UI layer from service to perform business
1
1

Example - Do logout in a CDI way
@Named
@SessionScoped
public class AccountBean implements Serializable {
@Inject
private Instance<AccountBean> myInstance;
public String doLogout() {
myInstance.destroy(myInstance.get());
return "/index";
}
Since CDI 1.1, Instance provides a destroy() method to remove an instance from its context
1
1

Back to demo
 AccountBean injects a reference to itself
 AccountBean destroys it for logout

Alternatives
 An alternative is a bean that must be explicitly selected
 When selected it superseeds beans sharing the same type
 A convenient way to create Mock or specific implementation
 An alternative can be activated in beans.xml or with @Priority

Alternative Example
public SapService implements ErpService {
}
@Alternative
public MockSapService implements ErpService {
}
@ApplicationScoped
public OrderService {
@Inject
ErpService service;
}
A service doing heavy or costly operation
Can be mocked with an alternative
Beans injecting the service have nothing to do. Alternative will replace the original bean if selected
1
2
3
1
2
3

Selecting the Alternative
 With @Priority annotaion (for the whole app)
@Alternative
public MockSapService implements ErpService {
}
 With beans.xml file (for the current module)
<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd">
<alternatives>
<class>com.acme.MockSapService</class>
</alternatives>
</beans>
1

Stereotypes
 Stereotypes are alias for annotations
 An help to avoid annotations Hell
 An other way to enable alterntives

Stereotypes
 we have a lot of bean with @Conversation and @Named
 we can create a stereotype gathering both
@Stereotype
@Named
@ConversationScoped
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE, ElementType.METHOD, ElementType.FIELD})
@Documented
public @interface Wizard {
}
We are delcaring a Stereotype
All the annotations we want to put in the stereotype
1
2
2
1
2

Using Stereotypes
 We can use the stereotype by replacing
@Named @ConversationScoped
public class ConferenceBean implements Serializable {
...
}
 by…
@Wizard
public class ConferenceBean implements Serializable {
...
}

Events in action
public class FirstBean {
@Inject Event<Post> postEvent;
public void saveNewPost(Post myPost) {
postEvent.fire(myPost);
}
}
public class SecondBean {
public void listenPost(@Observes Post post) {
System.out.println("Received : " + evt.message());
}
}
Event<T> is injected at the firing side. T is the event payload type (here my Post class)
When needed, we fire the event with our instance of T (here the Post object to save)
At the consuming side, we define an observer for a given payload type with @Observes annotation. If
observed type match fired event type, the observer is called.
1
2
3
1
2
3

Observer resolution mimics typesafe resolution (in a looser way)
postEvent.select(new AnnotationLiteral()<French> {}).fire(myPost);
}
}
public void listenFrPost(@Observes @French Post post) {}
public void listenPost(@Observes Post post) {}
public void listenObject(@Observes Object obj) {}
public void listenEnPost(@Observes @English Post post) {}
}
These observers will be triggered (empty subset is accepted for qualifiers when resolving observers)
This observer won’t be triggered
1
1
1
2
1
2

Hooking on context lifecycle with events
public void beginRequest(@Observes @Initialized(RequestScoped.class) ServletRequest req) {}
public void endRequest(@Observes @Destroyed(RequestScoped.class) ServletRequest req) {}
public void beginSession(@Observes @Initialized(SessionScoped.class) HttpSession session) {}
public void endSession(@Observes @Destroyed(SessionScoped.class) HttpSession session) {}
public void beginApplication(@Observes @Initialized(ApplicationScoped.class) ServlerContext ctx) {}
public void endApplication(@Observes @Destroyed(ApplicationScoped.class) ServlerContext ctx) {}
}
 Observer must be defined in a bean
 Observer resolution may trigger bean instance creation.
 So observers above are a nice way to initailize bean with its context

Back to demo
 BankingService is the observer
 ReimburseService fires the event
 The event is typed to Reimbursement

Introducing CDI
Portable Extensions

Portable extensions

One of the most powerful feature of the
CDI specification
 Not really popularized, partly due to:
1. Their high level of abstraction
2. The good knowledge on Basic CDI and SPI
3. Lack of information (CDI is often reduced to a basic DI solution)

Extensions, what for?
 To integrate 3rd party libraries, frameworks or legacy components
 To change existing configuration or behavior
 To extend CDI and Java EE
 Thanks to them, Java EE can evolve between major releases

Extensions, how?

Observing SPI events at boot time related to
the bean manager lifecycle
 Checking what meta-data are being created
 Modifying these meta-data or creating new
ones

More concretely

Service provider of the service
javax.enterprise.inject.spi.Extension declared in
META-INF/services
 Just put the fully qualified name of your extension class in this file
import javax.enterprise.event.Observes;
import javax.enterprise.inject.spi.Extension;
public class CdiExtension implements Extension {
void beforeBeanDiscovery(@Observes BeforeBeanDiscovery bbd) {
}
//...
void afterDeploymentValidation(@Observes AfterDeploymentValidation adv) {
}
}

Internal Step Happen Once Loop on Elements
Bean manager lifecycle
Deployment
Start
Before
Bean
Discovery
Scan
Archive
Process
Annotated
Type
After
Type
Discovery
Bean
Eligibility
Check
Process
Injection
Point
Process
Injection
Target
Process
Bean
Attributes
Process
Bean
Process
Producer
Process
Observer
Method
After
Bean
Discovery
After
Deployment
Validation
Application
Running
Before
Shutdown
Undeploy
Application

Example: Ignoring JPA entities
 The following extension prevents CDI to manage entities
 This is a commonly admitted good practice
public class VetoEntity implements Extension {
void vetoEntity(@Observes @WithAnnotations(Entity.class)
ProcessAnnotatedType<?> pat) {
pat.veto();
}
}

 Extensions are launched during
bootstrap and are based on CDI events
 Once the application is bootstrapped,
the Bean Manager is in read-only mode (no
runtime bean registration)
 You only have to @Observes built-in CDI
events to create your extensions
Remember

Understanding SPI to
build CDI extensions

SPI can be split in 4 parts
 Type meta-model

 CDI meta-model

 CDI entry points

 SPI dedicated to extensions

Why having a type meta-model?
 Because @Annotations are configuration
 but they are also read-only
 So to configure we need a mutable meta-model…
 …for annotated types

SPI for type meta-model
Annotated
Type getBaseType()
Set<Type> getTypeClosure()
<T extends Annotation> getAnnotation(Class<T>)
Set<Annotation> getAnnotations()
boolean isAnnotationPresent(Class<? extends Annotation>)
AnnotatedMember
X
Member getJavaMember()
boolean isStatic()
AnnotatedType<X> getDeclaringType()
AnnotatedParameter
X
int getPosition()
AnnotatedCallable<X> getDeclaringCallable()
AnnotatedType
X
Class<X> getJavaClass()
Set<AnnotatedConstructor<X>> getConstructors()
Set<AnnotatedMethod<? super X>> getMethods()
Set<AnnotatedField<? super X>> getFields()
AnnotatedCallable
X
List<AnnotatedParameter<X>> getParameters()
AnnotatedField
X
Field getJavaMember()
AnnotatedConstructor
X
Constructor<X> getJavaMember()
AnnotatedMethod
X
Method getJavaMember()

SPI dedicated to CDI meta-model
BeanAttributes
T
Set<Type> getTypes()
Set<Annotation> getQualifiers()
Class<? extends Annotation> getScope()
String getName()
Set<Class<? extends Annotation>> getStereotypes()
boolean isAlternative()
Bean
T
Class<?> getBeanClass()
Set<InjectionPoint> getInjectionPoints()
boolean isNullable()
Interceptor
T
Set<Annotation> getInterceptorBindings()
boolean intercepts(InterceptionType type)
Object intercept(InterceptionType, T, InvocationContext)
Decorator
T
Type getDelegateType()
Set<Annotation> getDelegateQualifiers()
Set<Type> getDecoratedTypes()
Producer
T
T produce(CreationalContext<T>)
void dispose(T)
Set<InjectionPoint> getInjectionPoints()
InjectionTarget
T
void inject(T, CreationalContext<T>)
void postConstruct(T)
void preDestroy(T)
InjectionPoint
Type getType()
Bean<?> getBean()
Member getMember()
Annotated getAnnotated()
boolean isDelegate()
boolean isTransient()
ObserverMethod
T
Class<?> getBeanClass()
Type getObservedType()
Set<Annotation> getObservedQualifiers()
Reception getReception()
TransactionPhase getTransactionPhase()
void notify(T)
EventMetadata
InjectionPoint getInjectionPoint()
Type getType()

SPI providing CDI entry points
Iterable
T
Iterator<T> iterator()
void forEach()
Spliterator<T> spliterator()
Instance
T
T get()
Instance<T> select()
Instance<T> select();
boolean isUnsatisfied()
boolean isAmbiguous()
void destroy()
CDI
T
Set<CDIProvider> discoveredProviders
CDIProvider configuredProvider
CDI<Object> current()
void setCDIProvider(CDIProvider provider)
BeanManager getBeanManager()
BeanManager
Object getReference(Bean<?>, Type, CreationalContext<?> )
Object getInjectableReference(InjectionPoint, CreationalContext<?> )
Set<Bean<?>> getBeans(Type, Annotation[])
Bean<? extends X> resolve(Set<Bean<? extends X>>)
void validate(InjectionPoint)
void fireEvent(Object, Annotation[])
boolean isQualifier(Class<? extends Annotation>)
boolean isStereotype(Class<? extends Annotation>)
boolean areQualifiersEquivalent(Annotation, Annotation)
boolean areInterceptorBindingsEquivalent(Annotation, Annotation)
Context getContext(Class<? extends Annotation>)
ELResolver getELResolver()
ExpressionFactory wrapExpressionFactory(ExpressionFactory)
AnnotatedType<T> createAnnotatedType(Class<T>)
InjectionTarget<T> createInjectionTarget(AnnotatedType<T>)
InjectionTargetFactory<T> getInjectionTargetFactory(AnnotatedType<T>)
BeanAttributes<T> createBeanAttributes(AnnotatedType<T>)
Bean<T> createBean(BeanAttributes<T>, Class<X>, ProducerFactory<X>)
InjectionPoint createInjectionPoint(AnnotatedField<?>)
some methods skipped
Unmanaged
T
Unmanaged(BeanManager, Class<T>)
Unmanaged(Class<T>)
UnmanagedInstance<T> newInstance()
UnmanagedInstance
T
T get()
UnmanagedInstance<T> produce()
UnmanagedInstance<T> inject()
UnmanagedInstance<T> postConstruct()
UnmanagedInstance<T> preDestroy()
UnmanagedInstance<T> dispose()
provides

SPI dedicated to extensions
BeforeBeanDiscovery
addQualifier(Class<? extends Annotation>)
addScope(Class<? extends Annotation>, boolean, boolean)
addStereotype(Class<? extends Annotation>, Annotation[])
addInterceptorBinding(Class<? extends Annotation>, Annotation[])
addAnnotatedType(AnnotatedType<?>)
AfterTypeDiscovery
List<Class<?>> getAlternatives()
List<Class<?>> getInterceptors()
List<Class<?>> getDecorators()
addAnnotatedType(AnnotatedType<?>, String)
AfterDeploymentValidation BeforeShutdown
AfterBeanDiscovery
addBean(Bean<?>)
addObserverMethod(ObserverMethod<?>)
addContext(Context)
AnnotatedType<T> getAnnotatedType(Class<T>, String)
Iterable<AnnotatedType<T>> getAnnotatedTypes(Class<T>)
ProcessAnnotatedType
X
AnnotatedType<X> getAnnotatedType()
void setAnnotatedType(AnnotatedType<X>)
veto()
ProcessBean
X
Bean<X> getBean()
ProcessBeanAttributes
T
BeanAttributes<T> getBeanAttributes()
setBeanAttributes(BeanAttributes<T>)
veto()
ProcessInjectionPoint
T, X
InjectionPoint getInjectionPoint()
setInjectionPoint(InjectionPoint)
ProcessInjectionTarget
X
AnnotatedType<X> getAnnotatedType()
InjectionTarget<X> getInjectionTarget()
setInjectionTarget(InjectionTarget<X>)
ProcessObserverMethod
T, X
AnnotatedMethod<X> getAnnotatedMethod()
ObserverMethod<T> getObserverMethod()
ProcessProducer
T, X
AnnotatedMember<T> getAnnotatedMember()
Producer<X> getProducer()
setProducer(Producer<X>)

All these SPI interfaces are events containing meta-model SPI

These events fired at boot time can only be observed in CDI
extensions
 For instance:

A ProcessAnnotatedType<T> event is
fired for each type being discovered at
boot time

Observing ProcessAnnotatedType<Foo>
allows you to prevent Foo to be deployed
as a bean by calling
ProcessAnnotatedType#veto()

 We got this Javadoc:
Back to demo

Back to demo We don’t have the code of the BillingService

Create a BillingServiceExtension which calls
BillingService
 Using observers BillingServiceObserver
 Extension has to be enabled

About CDI 2.0
 Work is in progress on CDI 2.0
 Come see the session "CDI 2.0 is coming" thursday 2pm room 8
 One of the new features is the asynchronous events
 The good news is: "you can test it today"

Asynchronous event example
postEvent.fireAsync(myPost);
}
}
public void listenPost(@ObservesAsync Post post) {
System.out.println("Received : " + evt.message());
}
}
We introduced a fireAsync() method
For backward compatibility we had to add an @ObservesAsync observer
1
2
1
2

Let’s test asynchronous event
 Weld 3 Alpha (preview of CDI 2.0 RI) is available
 WildFly includes a patch mechanism to upgrade implementations
 We can patch WildFly with a simple command
./jboss-cli.sh --command="patch apply ~/wildfly-10.0.0.CR4-weld-
3.0.0.Alpha13-patch.zip"

Back to demo
Let’s add asynchronous event

References
 CDI Specification - cdi-spec.org
 Code & slides repository - github.com/antoinesd/cdi-forge-uni
 Slides generated with Asciidoctor, PlantUML and DZSlides backend
 Original slide template - Dan Allen & Sarah White

Antoine Sabot-Durand
Antonio Goncalves
 @antoine_sd @agoncal

Extending Java EE with CDI and JBoss Forge

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Extending Java EE with CDI and JBoss Forge

Similar to Extending Java EE with CDI and JBoss Forge (20)

More from Antoine Sabot-Durand

More from Antoine Sabot-Durand (6)

Recently uploaded

Recently uploaded (20)

Extending Java EE with CDI and JBoss Forge