Oracle Blog

Arun Gupta's Weblog

Wednesday Jul 24, 2013

javax.enterprise.inject.spi.BeanManager allows to
programmatically obtain contextual references to beans. Even though
the primary purpose is to allow a portable extension to interact
directly with the container, it can be used by any Java EE component
as well.

Sunday Apr 24, 2011

The CDI specification (JSR-299) defines "Qualifer" as a means to uniquely identify one of the multiple implementations of the bean type to be injected. The spec defines certain built-in qualifiers (@Default, @Any, @Named, @New) and new qualifiers can be easily defined as well. This Tip Of The Day (TOTD) discusses the in-built qualifiers and how they can be used.

The @Named qualifier makes a bean EL-injectable, that's it!

The @Default qualifier, appropriately called as "default qualifier", exists on all beans without an explicit qualifer, except @Named. Consider the following bean type and implementation:

are equivalent. However it is not recommended to use @Named as injection point qualifier, except in the case of integration with legacy code that uses string-based names to identify beans.

@Any is another in-built qualifier on all beans, including the ones with implicit or explicit @Default qualifier, except @New qualified beans (more on this later). So the SimpleGreeting implementation is equivalent to:

then a request-scoped Greeting implementation (SimpleGreeting in this case) is injected. However if it is injected as:

@Inject @New Greeting greeting;

then the injected SimpleGreeting is in the @Dependent scope and only has @New qualifier (neither @Default or @Any).

I tried all of this using GlassFish 3.1 and NetBeans 7.0 that provides complete development and fully-clustered deployment environment for your Java EE 6 applications. Where are you deploying your Java EE 6 apps ?

Wednesday Apr 13, 2011

Sebastian Meyen, the chair of worldwide JAX Conference kick started JAX London 2011 with a very passionate opening session highlighting that JAX is all about Java, that they are comitted to Java, and not going to dilute the content. This is the 10th year of JAX conferences. Even though originally the word JAX was coined as an acronym for "Java Apache XML" indicating the open source nature and everything XML around Java but now its more popularly known as JAX.

The successful recipe for the JAX conference is "passion for the Java platform & ecosystem" and "a pramatic mix with development, architecture, agile, and other concepts around Java". In Sebastien's words "Java is a huge stake, heavily growing, innovating and worth focusing on it" and is a "rich environment for innovation". The JAX Innovation Awards giving $10,000 for the most innovative contributions to Java further proves their commitment to Java. Do you have the most innovative Java technology, most innovative Java company, and the top Java ambassador to recommend ? Submit now!

The first keynote of the day was by Dan North on the "Patterns of Effective Delivery". He highlighted several design patterns and the key ones were:

Spike and Stabilise - "Spike" is the non-TDD code written during the development cycle and then TDD applied to stabilise it for production.

Create Urgency - Create lots of instances where you are surprised, optimize for deliberate learning than for deliberate practice. Create an urgency for yourself for technologies that are genuinely useful. Difficult to change your thinking consciously, need a crisis.

Socratic Testing - Using the process of automated tests to draw out knowledge about the code.

Fits In My Head - Keeping the design small enough such that the entire design fits in your head, then you can reason the whole thing.

Being the chair of Java EE track, I spent most of my day attending the sessions there. The first session by Ales Justin explained how to run a Java EE application on Google App Engine. His slides are available below:

Ales explained his experience of building a sample application using JPA2, JSF2, Bean Validation, delpoing on GAE. The slides very well capture the restrictions of the platform and how he worked around them. The GAE API was even abstracted such that a pure Java EE application can be written and thus be portable across multiple application servers.

David Blevins's session on Fun with EJB 3.1 and Open EJB was indeed a lot of fun. He provided a good history of how the EJB and OpenEJB have evolved over years. There were lots of code samples highlighting the ease-of-use improvements done in EJB 3.1such as @Stateless, @Schedule, @Asynchronous, @Singleton, Embeddable EJB API and many others. I particularly loved his statement:

People who complain about EJB are stuck in 2005 and believe ignorance is my pride. Its testable, light, and pretty great!

Seriously, if you complain about EJB being heavy, non-functional, incomplete, the following code fragment is all it takes to create an EJB:

@Stateless
public class MyEJB {
public String myMethod(...) { }
}

and that too packaged in a WAR file, no deployment descriptors or any special packaging. Do you still think its heavy weight ? Think again!

Doug Clarke talked about "Java Persistence API 2.0 with EclipseLink", Joseph Shum talked about "Integrating Enterprise Applications into Liferay Portal", and then Dan Allen talked about "Using CDI Extensions to make a better Java EE". Dan showed several examples of how CDI extensions can be authored easily to extend capabilites of the existing platform. Their slides will be available on jaxlondon.com.

And I also gave two presentations:

GlassFish 3.1 - Simplifying your Java EE 6 Development and Deployment

OSGi-enabled Java EE Applications using GlassFish (in the OSGi track)

The first talk explained how several features in GlassFish 3.1 such as:

Deploy-on-Save (in NetBeans and Eclipse)

Active Redeploy (preserve sessions across re-deploys at CLI or NetBeans and Eclipse)

29% better startup/deploy/redeploy cycle

Application runner (java -jar glassfish.jar foo.war)

Maven integration (mvn gf:run, gf:start, gf:deploy, etc)

Embedded GlassFish

and many other features make GlassFish an extremely productive development environment for your Java EE 6 applications. And then features like:

High Availability, Clustering

Centralized Administration

Application-scoped Resources

Application Versioning

33% better High Availability performance

Better scalability - upto 100 instances per domain

RESTful monitoring and management

make it an equally compelling deployment platform. The slides with all the details are available below:

The first few slides are OSGi introductory so jump ahead to slide #22 for all the interesting stuff. The screencast #38 showcase how to build an OSGi-enabled Java EE Applications using Eclipse and GlassFish and comes with the complete and detailed instructions. The screencast #32 shows the same using NetBeans.

The day ended with a 1.5 hrs interactive Java EE 6 hackathon and more details on that in a later blog.

Saturday Dec 04, 2010

The
Rich
Web Experience 2010 concluded earlier this week in Fort
Lauderdale. In
a typical No Fluff
Just Stuff
fashion, it was truly a rich experience starting from the location
(hotel, city, and weather),
food, content, speakers, 90-minute sessions, schwag, and many other
items. There were about 350 attendees with topics ranging from HTML5,
CSS3, NodeJS, GWT, iPad /
iPhone / Android development, Grails, Git, Hudson, and pretty
much all over the landscape. I
gave three sessions on:

Java EE 6 = Less
Code + More
Power

Java EE 6 Toolshow

Using
Contexts and Dependency
Injection in the Java EE 6 Ecosystem

The first
session
explained the three themes of Java EE 6 (light-weight, extensibility,
and ease-of-use), explained newly introduced and updated specifications
in the platform, and finally the modular, hybrid OSGi/Java EE host,
embeddable, extensible, and high-availability nature of GlassFish. The
attendance was light but audience was interactive.

The
second session was a no-slides session and used NetBeans
and Eclipse
to
demonstrate the following Java EE 6 features:

The
third session on CDI was a revision of my JavaOne session with a lot
more context and code samples added. The talk explained CDI key
concepts like type-safe dependency injection, Qualifiers, Stereotypes,
Producer/Disposer, Alternative, Interceptor, Decorators, Scopes, CDI
tooling, and other topics.

On
a
personal front, I totally enjoyed coming from a 40 degrees weather in
San Jose to 70 degrees in Ft Lauderdale and that too with hotel right
on the beach. I had couple of great runs by the Atlantic Ocean and a
good walk along the
beach.

Thursday
had 2 hours dedicated for beach activity but I had to leave to catch my
flight to Washington DC :( The
dinner, lunch, and breakfast as part of the conference was healthy with
a good mix of salads + carbs + proteins. The lemon tea + honey allowed
me to deliver three 90 minute sessions in one day. And lastly enjoyed
catching up with Venkat, Matthew McCullough, Kohsuke, Ben Ellingson
and many other friends.

Here are some pictures:

And
the complete album:

Next
stop as part of No Fluff Just Stuff will be UberConf, Jul 12-16, 2011,
mark your dates!

Sunday Nov 21, 2010

One of the questions often asked in recently, and I've been wondering too, is how to enable transactions using CDI Interceptors. This Tip Of The Day (TOTD) will share some basic piece of code on how to author a CDI interceptor that enable transactions. TOTD #134 provide more details about interceptors. Weld documentation certainly provide good details about how all the pieces fit together.

This interceptor is injecting a "UserTransaction" and sandwiching the business method invocation between start and end of trnasaction. This interceptor is not dealing with any rollback scenarios or exception handling and so will need to be modified for a real-life scenario.

The code for this sample application can be downloaded from here. Just download and unzip the code, open the project in NetBeans (tried with 7.0 beta) and run it on GlassFish or any other Java EE 6-compliant container.

If you are using EJBs in a WAR, which is now allowed per Java EE 6, then you can certainly leverage all the annotation-driven transactions within your web application instead of maintaining your own interceptor-driven transactions. A similar approach can be used for security as well.

How are you dealing with transactions in your web application - using CDI-based interceptors or let the container manage it all for you ?

Tuesday Oct 05, 2010

Contexts & Dependency Injection (JSR 299) defines a standards-based type-safe Dependency Injection mechanism in the Java EE 6 platform. The type-safety comes from the fact that no String-based identifiers are used to identify the dependencies and instead all the information is specified using the Java object model. The loose coupling is possible because the bean requesting injection need not be aware of the lifecycle, concrete implementation, threading model and similar details of the injected bean. The CDI runtime automatically figures out the right bean in the right scope and context and then injects it correctly for the requestor.

CDI Events take loose coupling to the next level by following the Observer pattern. Event producers raise events that are consumed by observers. The event object carries state from producer to consumer.

Code is king, so lets understand the above text with a simple sample. Consider the following POJO that captures the state showing how many pages have been printed:

Any method with "@Observes" and the observed event type as parameter will receive the event. In this case, this method will observe all the events. However the observer can specify qualifiers to narrow the set of event notifications received. So lets create a CDI qualifier as:

Now, if we kept our original method "onPrint" in the consumer as well then each fired event will be delivered to this common method and the "qualified" method.

CDI also defines "Transactional observer methods" that receive event notifications during the different phases of a transaction in which the event was fired. There are pre-defined phases IN_PROGRESS, BEFORE_COMPLETION, AFTER_COMPLETION, AFTER_FAILURE, and AFTER_SUCCESS that allows you to receive and track events and take actions, if any, based upon the result. One use case is to keep the cache updated after receiving events when products are added / deleted from the database. Another use case is to it push data to the front end after a long-running transaction is successful.

You can certainly try all of this in GlassFish and NetBeans provides extensive tooling around CDI and broader Java EE 6. Check out screencast #30 for the complete Java EE 6 tooling using NetBeans.

Monday Aug 23, 2010

Contexts & Dependency Injection (CDI) in Java EE 6 provides type-safe dependency injection. The type-safety part comes from the fact that no String-based identifiers are used for dependency injection. Instead CDI runtime uses the typing information that is already available in the Java object model.

Java EE 5 already had resource injection available in terms of PersistenceContext, PersistenceUnit, Resource, and others. But they require String-based identifiers to identify the resource to be injected. For example:

@PersistenceUnit(unitName="SOME_NAME")

@Resource(name="JNDI_NAME")

@WebServiceRefs(lookup="JNDI_NAME_OF_WEB_SERVICE_REF")

The main proposition of CDI is type-safety. This Tip Of The Day explains how @Produces annotation provided by CDI can be used to centralize all these String-based resource injection and add a facade of type-safety on them. Specifically, it shows how type-safety can be achieved for @PersistenceUnit. A similar approach can be taken for other String-based resource injections as well.

The "EntityManagerFactory" can now be injected in the Servlet in a type-safe manner as:

@Inject @StatesDatabase EntityManagerFactory emf;

This procedure can be repeated for other String-based resources as well and thus centralize all of them at one place. And now your application becomes more type-safe! With this TOTD, you can use @Inject for injecting your container- and application-managed resources easily.

The specification is not entirely new as the concept is borrowed from the EJB 3.0 specification and abstracted at a higher level so that it can be more generically applied to a broader set of specifications in the platform. Interceptors do what they say - they intercept on invocations and lifecycle events on an associated target class. Basically, interceptor is a class whose methods are invoked when business methods on the target class are invoked and/or lifecycle events such as methods that create/destroy the bean occur. Interceptors are typically used to implement cross-cutting concerns like logging, auditing, and profiling.

The "@AroundInvoke" annotation (can be only one per interceptor) on a method in the interceptor class ensures that this method is invoked around the business method interception. This will be more clear after the program flow is explained later. Multiple interceptors can be chained and the flow/outcome may be diverted in any of them using "InvocationContext".

and then invoke the bean's method in "doGet" or "doPost" methods of the servlet as:

String result = bean.sayHello("Duke");

Notice that @Inject is used to inject the managed bean and bean discovery is enabled by adding an empty "beans.xml". This ensures that CDI inject works as expected and all the interceptors are invoked as well. Another alternative is to inject the bean using @Resource but "beans.xml" need to be removed in order for the interceptors to be invoked. So inject your bean using @Inject + "beans.xml" or @Resource. The recommended approach is to use @Inject + "beans.xml" as CDI might be used in other parts of your applications as well.

If 2 interceptors, each with a separate interceptor binding, managed bean class, and the servlet is included in a web application then the directory structure will look like:

If there are "System.out.println"s inserted at relevant positions in the interceptor and the Servlet code, then the code flow looks like:

Before Intercept
Before Intercept2
sayHello
After Intercept2
After Intercept
processRequest

"Before XXX" messages are printed by a method from the interceptors, in the order of chaining, before "context.proceed" is invoked in all the interceptors. "sayHello" method is invoked from the "doGet" or "doPost" method in the Servlet. "After XXX" messages are printed from the interceptors after "context.proceed" method is invoked, this time in the reverse order of chain. And finally "processRequest" method is invoked again from the "doGet" or "doPost" method in the Servlet.

The complete source code for the sample explained above can be downloaded here.

A short definition for a managed bean - its a POJO that is treated as managed component by the Java EE container.

There are several component specifications in the Java EE platform that annotates a POJO to achieve the desired functionality. For example, adding "@Stateful" annotation to a POJO makes it a stateful EJB. Similarly adding "@javax.faces.bean.ManagedBean" to a POJO makes it a JSF managed bean. Java EE 6 introduces a new specification - "Managed Beans 1.0" that provides a common foundation for the different kinds of component that exist in the Java EE platform. In addition, the specification also defines a small set of basic services:

Resource Injection

Lifecycle callbacks

Interceptors

The different component specifications can then add other characteristics to this managed bean. The specification even defines well known extension points to modify some aspects. For example CDI/JSR 299 relaxes the requirement to have a POJO with no-args constructor and allow constructor with more complex signatures. CDI also adds support for lifecycle scopes and events. Similarly EJB is a managed bean and adds support for transactions and other services.

A managed bean is created by adding "javax.annotation.ManagedBean" annotation as:

The standard annotations "javax.annotation.PostConstruct" and "javax.annotation.PreDestroy" from the JSR 250 can be applied to any methods in the managed bean to perform any resource initialization or clean up by the managed bean. A bean with lifecycle callbacks can look like:

Its important to provide a name to the managed bean, as there is no default name, for the JNDI reference to work. EJB and CDI specifications extend this rule and provide default naming rules.

Once the bean is injected then its business methods can be invoked directly.

As part of Java EE 6, all EJB and CDI beans are defined as managed beans and so:

@Stateless
public class FooBean {
. . .
}

and

@Named
public class BarBean {
. . .
}

are implicitly managed beans as well.

No other beans in the Java EE platform are currently implicitly defined as managed beans. However JAX-RS resources can also be defined as EJB and CDI beans in which case the JAX-RS resources will be implicit managed beans as well. A future version of different component specifications may discuss if it makes sense to align other Java EE POJO elements to align with Managed Beans specification.

This method queries the database for an actor by his id and uses the typesafe Criteria API to achieve the purpose. The FROM, SELECT, and WHERE clause are highlighted in the code. A cast to EclipseLink specific class is required because of the bug #303205.

This is a marker class to inform Jersey of the root resource to be registered. By default, all classes with @Path and @Provider annotations are included. It also specifies the base path at which all resources are accessible.

An alternative to this class is to specify the required information in "web.xml" as:

Standard JAX-RS annotations from "javax.ws.rs" package are used to represent the RESTful resource.

"getActor" method is invoked when the resource is accessed using HTTP GET.

The resource is accessible at "/actor/{id}" URL where "{id}" is mapped to the "id" parameter of "getActor" method.

SakilaBean is injected in a typesafe manner using @Inject annotation. This bean is then used to query the database using the "id" parameter.

"getActor" method produces JSON representation, as defined by the "@Produces" annotation. This is easily achieved by updating our Persistence Unit (PU) created in TOTD #122 and adding "@javax.xml.bind.annotation.XmlRootElement" as the class level annotation on "sakila.Actor" class. Make sure to install the updated PU to your local Maven repository.

Now the SOAP web service is accessible at "http://localhost:8080/simplwebapp-1.0-SNAPSHOT/SOAPServiceService" and looks like:

Notice, the URL in your case may be different if the Web service class name was different. The default URL is "http://<HOST>:<PORT>/<CONTEXT ROOT><WEB SERVICE CLASS NAME>Service".

This Web service can be easily tested by using the in-built tester accessible at "http://localhost:8080/simplwebapp-1.0-SNAPSHOT/SOAPServiceService?tester" and looks like:

The WSDL describing the Web service can be seen by clicking on the "WSDL File" link. The Web service method can be invoked by entering a value ("id" of the Actor) in the text box and clicking on "sayHello" button. Here is a sample run:

Clicking on "Submit" invokes the Web service which then uses the injected "SakilaBean" to query the database using the parameter specified. The first name from the response from the database is then extracted, concatenated with the string "Hello" and returned as Web service response.

The RESTful resource is accessible at "http://localhost:8080/simplwebapp-1.0-SNAPSHOT/sakila/actor/5" and looks like:

As in the SOAP-based Web service, the "5" in the URL is mapped to a parameter in the "ActorResource.java", the injected "SakilaBean" is then used to query the database and returns the JSON representation. Specifying a different number in the URL will show the RESTful JSON representation for that particular actor.

More Java EE 6 features will be covered in subsequent blogs. Are you interested in any particular ones ?