Java EE 5 Annotations and Resource Injection in some container managed components

The Annotations that are required by a Java EE technology compliant web container:

Annotations

@DeclareRoles (*)

@RunAs (*)

@EJB

@EJBs

@Resource

@Resources

@PersistenceContext

@PersistenceContexts

@PersistenceUnit

@PersistenceUnits

@PostConstruct

@PreDestroy

@WebServiceRef

@WebServiceRefs

Annotations must be supported on the following container managed classes that implement the following interfaces:

Component Type	Component Type Classes implementing the following interfaces	Notes
Servlets	javax.servlet.Servlet	Java Servlet Specification version 2.5 References must be injected prior to any lifecycle methods being called and the component instance being made available the application.
Filters	javax.servlet.Filter
Listeners	javax.servlet.ServletContextAttributeListener javax.servlet.ServletRequestListener javax.servlet.ServletRequestAttributeListener javax.servlet.http.HttpSessionListener javax.servlet.http.HttpSessionAttributeListener javax.servlet.AsyncListener
ManagedBean	JavaServer Faces Specification v 2.0 Only beans declared to be in request, session, or application scope are eligible for resource injection. Methods on managed beans declared to be in request, view, session, or application scope, annotated with @PostConstruct, must be called by the JSF implementation after resource injection is performed (if any) but before the bean is placed into scope. Methods on managed beans declared to be in request, session, or application scope, annotated with @PreDestroy, must be called by the JSF implementation before the bean is removed from its scope or before the scope itself is destroyed, whichever comes first. In the case of a managed bean placed in view scope, methods annotated with @PreDestroy must only be called when the view scope is destroyed.

(*) Annotations not allowed in Managed Bean

OO concepts: Adapter pattern

Introduction

In this post I sum up the Adapter pattern, an interesting OO pattern very useful in many situations. From my point of view, in the most enterprise situations where I needed to integrate with external systems, the idea of using adapter pattern provided to the systems a transparent way to communicate with other interfaces.

It is relevant to mention that this pattern is very important to build the ANTICORRUPTION LAYER in Domain Driven Design.

Description

Convert the interface of a class into another interface clients expect. Adapter lets classes work together that could not otherwise because of incompatibles interfaces.

Scenario

The figure shows a design of a Web search engine that queries the databases of multiple libraries.

Libray1SearchEngine and Libray2SearchEngine classes have already implemented. These two classes implement Searchable interface so that the SearchInvoker class can call them interchangeably.

Let assume that a search implementation for a third library is wanted. Most of the code is already written in the Libray3SearchEngine class.

This class is used in a previously developed client-server application. Unfortunately, Libray3SearchEngine does not have all the needed functionality and has a different interface than the other search engine classes. The library plans to continue using the previously developed client-server application, so if you modified Libray3SearchEngine, you would have to maintain two versions of the class. You don’t want to complicate SearchInvoker by making it deal with the different interfaces, so you need a way to adapt Libray3SearchEngine to the Searchable interface.

Solution

The Adapter pattern recommends creating a new Adapter class that implements the DesiredInterface and propagates requests to the existing Adaptee class. The Client class calls methods on Adapter, not on Adaptee. If the DesiredInterface requires some functionality that is not supported by Adaptee, Adapter can implement that functionality directly.

Object Adapter Strategy Structure

Class Adapter Strategy Structure

Solution in this scenario

Consequences

The advantages of using the Adapter pattern are:

§          The client class is not complicated by having to use a different interface and can use polymorphism to swap between different implementations of DesiredInterface.

§          The adaptee class is not modified.

The disadvantages of using the Object Adapter strategy are:

§          There are two objects involved, so you must create an additional object.

§          All requests are forwarded, so there is a slight increase in the overhead.

The disadvantages of using the Class Adapter strategy are:

§          The interface of the adapter class also supports the interface of the adaptee class, so the client is coupled to the adaptee class.

§          In Java programming language, the single subclassing slot for a class is used up in adaptation. Therefore, you must use interfaces to support other features.

References

Gamma, Helm, Johnson, and Vlissides 2004. Design Patterns. Elements of Reusable Object-Oriented Software. Addison-Wesley.