This quickstart shows off all the new features of Java EE 6, and how to use them with a RichFaces front-end. It makes a great starting point for your project.

Bean Validation

Bean Validation is a new specification in Java EE 6, inspired by Hibernate Validator. It allows application developers to specify constraints once (often in their domain model), and have them applied in all layers of the application, protecting data and giving useful feedback to users.

JAX-RS: The Java API for RESTful Web Services

JAX-RS is a new specification in Java EE 6. It allows application developers to easily expose Java services as RESTful web services. The kitchensink-rf application shows off a number of Java EE technologies such as CDI, JSF, EJB, JTA, JAX-RS and Arquillian. It does this by providing a member registration database, available via JSF and JAX-RS. The JSF front-end use RichFaces components for improved usability, and a mobile view is available using the RichFaces 4 mobile compatible components.

As usual, let's start by looking at the necessary deployment descriptors. By now, we're very used to seeing beans.xml and faces-config.xml in WEB-INF/ (which can be found in the src/main/webapp directory of the example). Notice however, that we have now introduced a web.xml. The web.xml file is the primary file used for configuring the RichFaces framework. In this quickstart we are using the web.xml file to enable resource optimisation. More on this later.

There are two configuration files in WEB-INF/classes/META-INF (which can be found in the src/main/resources directory of the example) —persistence.xml, which sets up JPA, and import.sql which Hibernate, the JPA provider in JBoss EAP, will use to load the initial users into the application when the application starts. We discussed both of these files in detail in Thegreeter example in depth, and these are largely the same. Next, let's take a look at the JSF view the user sees. As usual, we use a JSF template to layout the content, sidebar and footer.

This template lives inWEB-INF/templates/default.xhtml: The index.xhtml page places the content unique to the main page: The memberForm.xhtml composite component encapsulates the form elements into a single JSF component that can be re-used throughout the application. The mobile/index.xhtml page is served using URL a rewriting technique when the user-agent in the request header indicates the client is using a mobile web browser. We'll see both the URL rewriting configuration and the user-agent detection later.

This template lives inWEB-INF/templates/mobile.xhtml: To achieve the expected level of performance with our JSF/RichFaces application on mobile devices we will pursue a single page application model. This index page will dynamically load content via ajax calls, and use the slidfast library to slide content in and out of the screen. Next, let's take a look at the Member entity, before we look at how the application is wired together: Let's take a look at MemberRepository, which is responsible for interactions with the persistence layer: Next, let's take a look at MemberListProducer, which is responsible for building the list of members, ordered by name. It uses JPA 2 criteria to do this. Let's now look at MemberRegistration, the class that allows us to create new members from the JSF page Now, let's take a look at the Resources class, which provides resources such as the entity manager. CDI recommends using "resource producers", as we do in this example, to alias resources to CDI beans, allowing for a consistent style throughout our application: The UAgent info class parses the user-agent string retrieved from the browser request to identify the client browser. This is used to re-direct mobile browsers to the mobile index page. The UserAgent class is a CDI bean wrapping the UAgetnInfo class. It provides a simplified API we can query from EL in our JSF pages. The configuration file for the url rewriting library used to redirect mobile requests to the mobile index page. Of course, we need to allow JSF to interact with the services. The MemberController class is responsible for this: The PageBean maps the location hash from the url in the browser into a jsf view-id. This view-id will be used by the ui:include tag in the mobile index to load the page content. Before we wrap up our tour of the kitchensink example application, let's take a look at how the JAX-RS endpoints are created. Firstly, {JaxRSActivator}}, which extends Application and is annotated with@ApplicationPath, is the Java EE 6 no XML approach to activating JAX-RS. The real work goes in MemberResourceRESTService, which produces the endpoint: Right-click the project and select Run As > Run On Server or click on the "Click to Perform" link below. If you've been following along with the Test Driven Development craze of the past few years, you're probably getting a bit nervous by now, wondering how on earth you are going to test your application. Lucky for you, the Arquillian project is here to help!

Arquillian provides all the boiler plate for running your test inside JBoss Enterprise Application Platform 6, allowing you to concentrate on testing your application. In order to do that, it utilizes Shrinkwrap, a fluent API for defining packaging, to create an archive to deploy. We'll go through the testcase, and how you configure Arquillian in just a moment, but first let's run the test. Arquillian defines two modes, managed and remote. The managed mode will take care of starting and stopping the server for you, while the remote mode connects to an already running server.

The following action starts the test in the remote mode because you have started the server in the previous step.
Right-click the project, select Properties>Maven and enter arq-jbossas-remote to the Active Maven Profile field. After that, right-click the project and selectRun As>JUnit test. So far so good, the test is running. But what does the test look like? As you can see, Arquillian has lived up to the promise - the test case is focused on what to test (the @Deployment method) and how to test (the @Test method). It's also worth noting that this isn't a simplistic unit test - this is a fully fledged integration test that uses the database.

Now, let's look at how we configure Arquillian. First of all, let's take a look at arquillian.xml insrc/test/resources. Now, we need to look at how we select between containers in the pom.xml: And that's it! As you can see Arquillian delivers simple and true testing. You can concentrate on writing your test functionality, and run your tests in the same environment in which you will run your application.

Arquillian also offers other containers, allowing you to run your tests against Weld Embedded (super fast, but your enterprise services are mocked), GlassFish, and more.

More info on Arquillian you can find on the Arquillian project page. What we didn't tell you about the Kitchensink-rf quickstart is that it is generated from a Maven archetype. Using this archetype offers you the perfect opportunity to generate your own project.

In order to perform that, you should select Help>JBoss Central and click the RichFaces Project wizard.
You will get a brand new project with the same functionality askitchensink-rf, but customized with your details.