Here’s a quick tutorial on how easy it is to get started with JSF 2.0 and JSR 299, Java Contexts and Dependency Inject (CDI) using the latest release of Netbeans 6.8.

Read Part 1
Read Part 2
Read Part 3

Getting Netbeans and JEE6

First download the latest version of Netbeans (at the time of writing 6.8 has just been released). Make sure the download version you choose includes Glassfish V3 and java web and EE. Once downloaded, install it and get it up and running and we can start writing the application.

Starting the Project

Once Netbeans is up and running, start a new web project by clicking New Project and select the Java Web category and select a Web Application project and click next.

Give the new project a name (I called mine ee6demo) and a directory and click next. On the server settings, Glassfish v3 should already be selected so select next. In this tab, make sure Java Server Faces is selected and stick with the defaults in the lower panel that appears when you select it.

You can now click finish and Netbeans will create the project and open it up for you in the IDE. On the left you can see the project explorer and in the main tab you can see a file called index.html. Without doing anything, open the Run menu in the main menu and select “Run Main Project”. After a moment of activity and console logging a web browser window should open up with the message “Hello From Facelets” which is exactly what we can see in the index.xhtml file. So far, we haven’t done anything and we already have a working web application shell.

Just take a moment and look at the tabs on the left hand side, you should see Project,Files, and Services. Click on the services tab and expand the Servers node and you should see the Glassfish server we are using with a little green arrow on it indicating that the server is running. For now, we don’t need this because we aren’t actually going to deploy to the server again, no restarts and no manual deployments, so go back to the projects tab on the left.

Adding some code

In the projects tab, expand the “Source Packages” node and right click and select New->Java Class. Give the class the name MessageServerBean and a package name (I used eedemo). We annotate the class with the javax.inject.Named annotation and a single method to return a string.

package eedemo;

import javax.inject.Named;

@Named
public class MessageServerBean {

    public String getMessage() {
        return "Hello World!";
    }
}

This a managed bean as defined by CDI which in Glassfish v3 is implemented using Weld from JBoss. One thing we need to do now is tell the server that this project is a module containing CDI beans. We add a file called beans.xml to the project in the WEB-INF folder. Right click on the WEB-INF folder in the project manager in the ee6Demo/Web Pages/folder and select New->XML Document. In the file name editor, just call it beans, not beans.xml as the IDE will add the xml extension for you and if you add the xml extension, the file will be called beans.xml.xml (I’ve often tripped myself up with that one!). Open the beans.xml file in the editor, and select all the text and delete it so it is an empty file. You could alternatively just put . (Note This file can be used to specify bean related information in xml so you aren’t limited to annotations)

The last change is to edit the index.xhtml and replace the “Hello From Facelets” with our own text.

        Message is : #{messageServerBean.message}<br/> 
        Message Server Bean is : #{messageServerBean}

Save it and go to your browser and refresh the page (http://localhost:8080/ee6demo/).

Message is : Hello World!
Message Server Bean is : eedemo.MessageServerBean@xxxxxxx

You should now see the message from the bean displayed on the page. Now go back into your message bean and change the message to something else (I used Hello From Weld!), save the file and then refresh the browser. Your new message appears automatically since your application code has been hot deployed automatically by Netbeans . If you don’t see your changes just give it a second and refresh again.

From the second line in our page you can see that the class name is eedemo.MessageServerBean and the bean is just a pojo. Even though this is JEE, there is no complex class hierarchy wrapped in layers of transactions, interceptors and all that ‘Heavy’ stuff you keep hearing about.

What’s going on?

When the application is deployed, the presence of a beans.xml file signals that this module contains CDI managed beans so the classes on the path are scanned for CDI annotations. Our bean was annotated with the @Named annotation and so this class was registered with Weld (under that name) (edit in a CDI module, all beans are registered with Weld, the named annotation is just used to match beans to injection points). When our JSF page was rendered, JSF tried to resolve the value of messageServerBean in the page using the registered expression resolvers in JSF. One of these is the Weld EL Resolver which has the MessageServerBean class registered under the name messageServerBean. We could have specified a name with the annotation, but since we didn’t it was registered under the default name of the class name with a lower case first name. The Weld resolver returns an instance of this bean in response to the request from JSF. Bean naming is only needed when using EL expressions and should not be used as the default mechanism for injection. CDI provides type safe injection by class type and stereotypes or qualifiers as we’ll see later.

Upgrading to an EJB

As we are using a JEE stack, we can easily deploy our bean as an EJB with some small changes thanks to EJB 3.1. Just open up the MessageServerBean and add the javax.ejb.Stateless annotation at the class level. Again, just save the file and go to your browser and refresh (no manual deploying, just save the file), and you should see something like :

Message is : Hello From Weld!
Message Server Bean is : eedemo.__EJB31_Generated__MessageServerBean__Intf____Bean__@xxxxxxx

Amazingly, we turned our pojo bean into a fully featured EJB with just one annotation, we saved it, and refreshed our page and our changes appeared, we don’t have to create any weird project configurations, local interfaces or arcane deployment descriptors.

Different EJB types

You can also try using the @Stateful annotation (don’t forget to implement the java.io.Serializable interface in the bean as it needs to be able to passivate (edit This isn’t necessary for it to be an EJB, but it is necessary if you want it to be session or conversation scoped)). Alternatively, you could try the new @Singleton annotation for singleton instances. If you do, you may notice that there is a javax.ejb.Singleton and javax.inject.Singleton. Why two Singleton annotations? A single annotation in CDI lets you define a singleton instance outside of EJB in case you are using CDI in a non-EJB environment. An EJB singleton will have all the features of an EJB such as transaction management so you have the choice depending on your needs and whether the environment is EJB or not.

In this first part, we have created a new JSF 2.0 application, made it CDI enabled and added a managed bean which we then referenced from the web page. In part 2, we’ll start looking at creating more complex beans and injecting them into and with other beans.

Click to view Part 2

Tagged: , , , , ,