Oracle Blog

Arun Gupta's Weblog

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!

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.

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 ?

Friday Oct 02, 2009

This entry is a follow up to TOTD #95 and shows how to use the recent integrations of JSR 299 in GlassFish v3 to convert a JSF managed bean to a JSR 299 bean (aka Web Beans). The TOTD #95 describes a simple Java EE 6 web application that uses Java Server Faces 2.0 components for displaying the results of a database query conducted by EJB 3.1 and JPA 2.0 classes.

Add the required entity classes explicitly to "persistence.xml". If the persistence unit is injected then the container automatically scans the web application root for any entity classes.

Expand "Configuration Files" and edit "persistence.xml".

Uncheck "Include All Entity Classes in ..." check box.

Click on "Add Class...", select "state.States", and click on "OK".

That's it, re-deploy your application and now you are using the Web Beans integration in GlassFish v3 instead of JSF managed bean. The output is available at "http://localhost:8080/HelloEclipseLink/forwardToJSF.jsp" as shown: