First, some theory. JSF has support for something called “attached objects”. This has been since the very beginning, with Converters and Validators.
Since JSF 2.0, Behaviors have been added to this list. A Behavior, when attached to a component, adds client side scripts to an object. For example, one can imagine a Behavior to do an Ajax request, load some data and show it on the page. This will be a common use case for behaviors. The Expert Group understood this and came up with a specialized AjaxBehavior, which is quite similar to the Ajax4jsf <:a4jsupport /> tag. it adds Ajax functionality to the existing component, without modifying it.

This is ClientBehavior in a nutshell. There are more subtile things to know, see this article by Andy Schwartz for a more thorough explanation of the subject.

From now on, I assume at least basic ClientBehavior knowledge and of course JSF knowledge.

The ValidateBean Behavior
With Java EE 6 we got Bean Validation. And I must admit, I like it a lot. It has a nice declarative language and one ubiquitous model for defining validations for your entire system, from database (generating Bean Validation-aware DDL with JPA 2.0) to UI (the JSF 2.0 BeanValidator, which I implemented for Apache MyFaces. That’s where my enthusiasm started).

But, one validation is missing in the spec (with good reasons of course), namely client side JavaScript validations, to improve usability and decrease server load.

Especially since JavaScript validations are often skipped because of maintenance reasons (validations implemented twice) and we now have a robust platform to implement generic validations, I tried to combine the two new technologies (ClientBehavior and Bean Validation) into one generic JavaScript validator.

The ClientBehavior implementation

This class has some interesting things. First, of course the annotations. @FacesBehavior simply registers the class as a ClientBehavior under the given name, just like how Managed Beans or Converters work. The second annotation defines a @ResourceDependency. A ResourceDependency simply says: “Hey JSF, I generate markup which depends on this file. Make sure it’s available”. And JSF 2.0 responds with: “Okay, I will”.

Also, you probably noticed my ClientBehavior to only understand buttons. That’s right, you need to attach it to a button and it takes care of wiring all field validations in the form.

It also looks for a messages component. This is used later to make sure the JS error messages are positioned the same as the by JSF generated messages. UIMessages applies to the entire view, so I don’t just look in the form. A high performance implementation may choose to start searching near the form, since most messages are positioned there, but that’s way out of scope of this article.

I know, I know, this is not the most elegant piece of code, but it nicely illustrates the point. I simply aggregates as much validation metadata as possible and writes it into one big JavaScript statement. Not that optimal, but high performance implementations may choose to dynamically generate a JS file with all metadata which only needs to be referenced from the inline JS code.

If you’d like to know how to obtain the ConstraintDescriptors (the four method calls in the above snippet), just look for the BeanValidator in the Apache MyFaces SVN. I reused the same code here.

The JavaScript
The JavaScript shown below is part of the static scripts that belong to the ValidateBeanBehavior. It contains the JavaScript code to execute the rules, as passed from the server and, if needed, show the validation errors.

It’s a lot of code, which, in essence, validates all input fields in the given form, according to the given validation rules and shows the user an error if needed. This error is positioned at the same spot as where the UIMessages would have been rendered in case of a server side error. This is a best guess though, because when the messages are not rendered (i.e. on the initial request), there is no marker in the page that I can use for positioning. A more sophisticated implementation could enrich all UIMessages in the page to always write some marker “div” with an ID to the client.

I’m going to skip the rest of the JavaScript. It’s just a bunch of validations and utilities, like utilities to convert Strings to and from Date Objects, based on a SimpleDateFormat pattern. This pattern is part of the generated JavaScript and is obtained by looking at the attached Converters.

Usage in a Facelet
To make the ClientBehavior a bit easier to use, here’s a Facelets taglib which defines a tag for the ClientBehavior (don’t forget to configure the taglib in web.xml or put it in the /META-INF of a JAR).

With the taglib in place, we can use the ClientBehavior, like this:

That’s not too much effort for a client side form validation right? And, these validations are always in-sync with the server side validations.

After a bit of cleanup, I’ll commit the code into the Apache MyFaces Sandbox, so you can download it from there when I’m done.

There’s is a good old application from the days when struts still had to be invented and framesets weren’t considered evil. The problems associated with a FRAMESET are another topic, the fact is the application owner wants to get rid of them and asked me to look for a solution that would be unobtrusive and easy to implement, understand and maintain.

Current Situation

The application uses no web-app framework, each Use Case is implemented in a separate servlet, all of them neatly mapped in the web.xml. The FRAMESET setup is classic: apart from the static elements, the navigation happens in a ‘body’ and a ‘menu’ frame. The normal flow is to select a command from the menu frame, e.g. Place Order results in (<a href=”/placeorder” target=”‘body”/>), then submit a few forms in the body frame (<form action=”/placeorder” method=”POST”>…</form>). Without frameset, when a HTTP request for /placeorder reaches the application, we want the servlet response decorated with the other fragments: menu, header and the rest. The differences are essential: there is just one request/response and all page fragments have to share the same HEAD, CSS etc.

Introducing Apache Tiles 2

The good news is that version 2.x of Apache Tiles, which has started as struts extension, is now framework-independent. It offers support for JSP, Freemarker, and can be used directly from a servlet or filter. First of all, a template is needed to replace the frameset, e.g. main.jsp:

Based on that template a tile definition can render a decorated view of any servlet output (e.g. /placeorder). A definition per servlet is needed in tiles.xml:

This definition still has to be rendered, e.g. from another JSP, let’s call it placeholder_tiled.jsp:

A separate tile definition and a JSP page for each servlet would be too much code repetition. Let’s see how to the output of any servlet.

A View decorating servlet

I like the idea of having separate URLs for the servlet output and for a composite view of the same output. Thanks to Tiles 2 API, one servlet could provide decorated views of the output of all servlets. In tiles.xml, I added a tile definition with all attributes except body defined:

Let’s define a servlet that will fill in the missing body attribute for each URL ending with .tiled:

Finally, the servlet itself:

This servlet always renders the same tiles definition, providing an appropriate body. For example, a request to /showOrder.tiled?orderId=100 would render the output of /showOrder?orderId=100 as the body tile in the tiles definition. No separate tiles definition and JSP for each view are needed.

What’s next?

All the code above only provides an easy template-decorated view for each servlet output. There is sill a lot of work that has to be done manually:
- move all separate styles, scripts etc. from the separate pages to the template
- requestDispacher.forward in a servlet closes the output stream while it is still needed for the tiles template; all forwards must become includes;
- all navigation javascript referring to top.menu ot top.body has to be refatored manually.

First, what’s a parametrized ConstraintValidator? Simple, a Validator that takes a parameter to do its job. A simple example is a length validator that takes the minimum and maximum length as parameters and validates if the value is between those two.

Parametrized ConstraintValidators are everywhere, even Bean Validation itself contains them. For example: @Min(length) and @Max(length), but also normal ConstraintValidators, like @NotNull where you can customize the error message. However, this error message parameter is not very interesting with regards to unit testing individual ConstraintValidators, because the message is generated by the Bean Validation framework.

For example, consider this ConstraintValidator, incl. corresponding annotation:

In the future, Bean Validation may become the core mechanism for ensuring correctness in your system. For example, JPA 2.0 leverages Bean Validation annotations to generate additional DDL statements and JSF 2.0 automatically uses Bean Validation when it’s available. Note: JSF 2.0 uses a new concept, called “default validators” to implement this. A default validator is invoked on every input component on a postback.

But, how do we test this stuff? After all, you can’t instantiate an annotation.

I currently have 4 options:

• Using reflection to use a declared annotation
• Custom annotation implementation
• Dynamic proxies
• Mocking, for example using Mockito

Using a declared annotation
The first attempt is shown below. Here, I simply declare the annotation in my test case on a dummy instance field (an annotation doesn’t live on its own) and look it up using reflection. This way, Java takes care of instantiating and initializing the annotation.

I personally quite like this approach. The test data is inside the test case. Unfortunately not in the test method, that would be better, but since you can’t put annotations everywhere in your code, it’s not easy to implement this decently.

So let’s look at the next one…

Custom annotation implementation
Since Java annotations are just a special case of interfaces, they should be fairly straightforward to implement. However, for some reason, I didn’t know this until recently. But it’s actually not different from any other interface implementation. See for yourself.

Nothing special, right? But I don’t really like it. I could have also written it inline, but I don’t like that either:

I think the above one looks like garbage. So this is also a no-go.

Dynamic proxies
Java itself uses dynamic proxies at runtime to instantiate annotations. So why not also use a Proxy to mock the annotation? See for yourself.

However inline, the implementation looks very clumsy. Unfortunately this is probably as simple as it can get, since you DO need to define the inner class.

And it will become even worse when there are multiple parameters on the bean, since you need to check which method is invoked. This will make the implementation even worse.

Mocking using Mockito
But, creating and configuring proxies, isn’t this what mocking libraries do? Exactly, let’s try.

This looks pretty nice. And it scales well with multiple attributes.

I only doubt it will be the nicest solution when the annotations become more complex. I really don’t like annotations that contain annotation parameters. Or even worse, arrays of annotation parameters. But reality is, they exist. And if they exist, they also need to be tested. But, OTOH, people who nest annotations probably don’t mind unreadable unit tests.

Suppose we have a class B which extends A and a class C which has class A as a member as shown below.

The following test will fail with a ClassCastException on the last line.

The methods save(), clearSession() and retrieve() are just helper methods which implement the Hibernate session methods save(), clear() and get().

A search on the Internet shows a couple of solutions for this problem.

1. Using interfaces as a proxy in the hibernate mappings. This will result in accessing the object through its interface only so all methods must be exposed in the interface. I don’t want to expose every public or protected method in the interface which are not intended for use by external parties.
2. Using the Visitor Pattern to access the correct childclass. This means that users of these objects must write a lot of code just to use some getters. I don’t want to burden someone else with a local Hibernate problem.
3. Using ((HibernateProxy)object).getHibernateLazyInitializer().getImplementation() whenever a typecast of an object to its child class is needed.

All of the solutions mentioned above are not suitable for me so I decided on another solution which is a variant of solution 3.

With a slight modification of the method getA() in class C, exposing the HibernateProxy is avoided.

Now the test completes without failure.

This has to be done for every getter which can return a lazy loaded proxy.

And if you (like me) don’t want Hibernate code in your domain model, you can move this code to the persistence layer and use dependency injection to use it.

It’s still not an elegant solution (IMHO there isn’t one), but its the best usable for me.

Also, you can completely configure the server in your POM, centralizing configuration and making it thus easy to store server settings in version control. Also, the mvn-jetty-plugin benefits from your existing Maven project configuration, like dependencyManagement.

Some of my buddies at Apache even use the maven-jetty-plugin on a daily basis for their real work. I never got this far, mostly because I’m more familiar with Tomcat, but also because I didn’t really see it as a mature development tool. However, today I decided to give it a chance.

The first attempt
So, I created a simple webapp in my favorite IDE: IntelliJ IDEA and added a Maven2 POM to enable Maven2 support. All well so far.

This was the initial version of my POM:

All was fine, my test app was running, but I needed to enable Unified EL to test MyFaces BeanValidator.

Adding UEL libraries
So, I added a dependency to the UEL API and Impl in my POM, but there was an issue. Every web container already provides the old Expression Language in the jsp-api.jar. So I’m not allowed to package my own EL libraries.

However, I’m quite stubborn, so I tried anyway:

So, let’s give it a try:

mvn jetty:run-exploded

(MyFaces 2.0 requires exploded deployment in Jetty).

Result? BOOOM!

The fix, replacing libraries
The error is completely appropriate. You’re just not allowed to package your own version of the servlet libraries. That’s the job of the servlet container. Failing to do so will result in the error shown above.

So we need to fix this issue by somehow replacing the Jetty libraries or at least changing the way Jetty loads its jsp-api.jar. This is no trivial task however, since jetty is initialized by Maven and doesn’t have a fixed directory structure on disk.

So we need to have some way in Maven to configure the Jetty libraries.

First, Jetty doesn’t have an endorsed mechanism, so that’s a no-go.

But the fix is actually quite easy, just pass some dependencies into the jetty plugin in the POM.

The final POM looks like this:

As you can see, Maven takes care of the heavy lifting. You only need to specify your dependencies and they will override any dependencies with the same groupId, artifactId and type.

So, now I don’t have any reason not to use mvn-jetty-run to test my code!

Happy coding!

GlassFish v3 is an open source application server and is the first compatible implementation of the Java EE 6 platform specification. To test the examples in this article I will assume that you use GlassFish (or any other JEE6 enabled application server) to run the examples.

Maven2 dependencies

Lets start with the Maven dependencies, you can add them all to the pom.xml of your war. I have also included Sun’s Maven2 repository for downloading the JEE6 dependencies like the javaee-api and Sun’s JAX-RS 1.1 implementation called Jersey.

Both dependencies are scoped as provided because GlassFish already ships with these libraries. In fact, my war file is not bigger than 22kb. JEE6 allowes developers to package full blown JEE application as a web archive file, there is no need for an enterprise archive anymore. This makes JEE6 applications really light weight.

JAX-RS RESTfull services in JEE6

JAX-RS supports configuration through annotations, just like the Spring 3.0 REST annotations. Annotations can be added to both classes and methods. Classes in JAX-RS can be POJO`s. One thing about JAX-RS is that it does not integrate well with other JEE specification, for example the JSR-330 annotations for dependency injection are not supported by JAX-RS (yet), but there is a workaround

Because of the flexibility of JAX-RS it is possible to annotate EJB SessionBean or CDI components with JAX-RS annotations. So when a bean with JAX-RS annotation is packaged in a war file, the annotations are automatically picked up by the JAX-RS implementation (Jersey in this case). Since EJB3.1 SessionBeans and CDI components support all of the dependency injection features offered by JEE6, JAX-RS now does too!

Below is an example JAX-RS annotated class. The goal of this RESTfull service is to expose two methods of the ProductService through a RESTfull interface. The ProductService is injected using the @Inject annotation.

In JAX-RS the @Path annotation is used to map an URI to a REST service. In the example below I’ve defined the @Path annotation on the class, this will map all the URIs starting with /product to this class. I also defined the @ManagedBean (CDI) annotation on the class for the @Inject to work properly.

There are two methods within the service which are annotated with @Path, @GET and @Produces. The @Path is the same as with the class, but in this case it maps URI’s to a method. The URI of a method is relative to URI specified in the @Path annotation
on the class. So the following URLs are mapped in this example:

JAX-WS allowes for mapping HTTP methods like GET, PUT, POST and DELETE to Java methods with the @GET, @PUT, @POST and @DELETE annotations. In this example only the GET method is used. In RESTfull service the HTTP GET is used to retrieve data. To map a GET request to a method you can simply annotate a method with @GET.

The @Produces annotation specifies the Mime-Type of the response data the methods produces. In this example the methods both produce XML data, therefore we need to set the Mime-Type to application/xml. When returning an Object from a method annotated with @Produces, JAX-RS trieds to find an appropriate converter to produces the output. In this case I will use JAXB will to marshall the Objects to XML (see below).

JAXB marshalling

In order for JAXB to marshall the Objects returned, we need to specify JAXB annotations on the Objects returned from the methods.
In this example I’ve added @XmlRootElement to the returned Objects to simply marshall the entire Object to XML.

Adding Jersey to the web deployment descriptor: web.xml

For JAX-RS to work we still need to add a Servlet to the web.xml which maps URL’s to the services. In this case we need to add the JerseyServlet to the web.xml. In the servlet-mapping all /rest/ URL patterns are mapped to Jersey. We can access the REST services using the following URIs: /rest/product/etc.

Conclusion

When building RESTfull services on an JEE6 enabled application server, JAX-RS really makes things easy. You will have to decide for your specific case if you want to use Spring or JAX-RS.

Using this container in Websphere (6.0, 6.1, 7) some problems occur when you want to do the following:

• You use a resource environment reference for your destination, specified in the web.xml, for the Destination.
• You use the property destinationName on the DefaultMessageListenerContainer in combination with a JndiDestinationResolver to look up your resource environment reference like this: java:comp/env/jms/(your destination)

problem
When you try to start the application, you will get an exception like this: javax.naming.NameNotFoundException: Name "comp/env/jms/(your destination)" not found in context "java:"., although you are sure that your resource environment reference is defined correctly.

cause
The cause of this problem lies in the fact that the lookup occurs in a Thread started by the DefaultMessageListenerContainer, which is unmanaged by Websphere. This thread will not have the jndi queue bindings in its InitialContext.

solution
You can either:

1. Specifiy the jndi object beforehand with a JndiObjectFactoryBean, or a
<jee:jndi-lookup id="myqueue" jndi-name="java:comp/env/jms/(your destination)"/>, and then
   setting the destination property of the DefaultMessageListenerContainer to the ref myqueue, so no actual lookup occurs within the thread of the listener itself.
2. Delegate the listener’s thread to Websphere with the help of the Spring class WorkManagerTaskExecutor. You can then set the property taskExecutor on the message listener container to reference this class. See the IBM article here for details on how to do this.

It was a talk by Pete Muir of JBoss. He was showing a really simple use case and tried to implement it using CDI. The talk was really technology driven and I hated it. Why? Because it wasn’t an improvement compared with the existing technologies. He wrote an application, containing several interfaces, classes (this is not bad) and custom annotations. If the goal was to show some kind of geniosity, it was a good talk. But if the goal was to show how this new technology would make our lives better… then sorry, he failed miserably.

More than a year further, there have been a lot of movements on the CDI front. And, as an Apache MyFaces developer, I’m of course very interested how to use CDI in a JSF 2.0 application. And as an Apache fanboy, I of course prefer Apache software, in this case MyFaces with OpenWebBeans and OpenJPA.

Configuration
Since OpenWebBeans is still under development, you need to do some additional steps to get it to work.

The following POM should get you up and running quickly in Tomcat:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>org.apache.myfaces</groupId>
    <artifactId>myfaces-example-ebanking</artifactId>
    <version>1.0-SNAPSHOT</version>
    <packaging>war</packaging>

    <dependencies>
        <!-- Compile dependencies -->
        <dependency>
            <groupId>org.apache.myfaces.core</groupId>
            <artifactId>myfaces-api</artifactId>
            <version>${myfaces-version}</version>
            <scope>compile</scope>
        </dependency>
        <dependency>
            <groupId>org.apache.myfaces.core</groupId>
            <artifactId>myfaces-impl</artifactId>
            <version>${myfaces-version}</version>
            <scope>compile</scope>
        </dependency>
        <dependency>
            <groupId>org.apache.openjpa</groupId>
            <artifactId>openjpa-all</artifactId>
            <version>${openjpa-version}</version>
            <scope>compile</scope>
        </dependency>
        <dependency>
            <groupId>commons-digester</groupId>
            <artifactId>commons-digester</artifactId>
            <version>2.0</version>
            <scope>compile</scope>
        </dependency>
        <dependency>
            <groupId>org.apache.openwebbeans</groupId>
            <artifactId>openwebbeans-impl</artifactId>
            <version>${openwebbeans.version}</version>
            <scope>compile</scope>
        </dependency>
        <dependency>
            <groupId>org.apache.openwebbeans</groupId>
            <artifactId>openwebbeans-jsf</artifactId>
            <version>${openwebbeans.version}</version>
            <scope>compile</scope>
        </dependency>
        <dependency>
            <groupId>org.apache.geronimo.specs</groupId>
            <artifactId>geronimo-interceptor_1.1_spec</artifactId>
            <version>1.0.0-EA1-SNAPSHOT</version>
            <scope>runtime</scope>
        </dependency>
        <dependency>
            <groupId>javax.annotation</groupId>
            <artifactId>jsr250-api</artifactId>
            <version>1.0</version>
            <scope>compile</scope>
        </dependency>

        <!-- Test dependencies -->
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <scope>test</scope>
            <version>${junit-version}</version>
        </dependency>
    </dependencies>

    <repositories>
        <repository>
            <id>Apache MyFaces beta</id>
            <name>Apache MyFaces beta</name>
            <url>http://people.apache.org/~lu4242/myfaces200beta</url>
        </repository>
    </repositories>

    <properties>
        <myfaces-version>2.0.0-beta</myfaces-version>
        <openwebbeans.version>1.0.0-SNAPSHOT</openwebbeans.version>
        <openjpa-version>2.0.0-M3</openjpa-version>
        <junit-version>4.7</junit-version>
    </properties>
</project>

Note some of the additional dependencies required to run in Tomcat, as opposed to a full blown appserver.

Also, at the moment you need to build OpenWebBeans from source manually. The geronimo-interceptor_1.1_spec dependency will be downloaded to your local Maven repository on a “mvn install”. OpenJPA is not needed for this simple use case, but I use it in my project.

Code
And then, the real code:

public class WebUtils {
    private static volatile String basePath;

    @Produces @Named public String getBasePath() {
        if (basePath == null) {
            basePath = FacesContext.getCurrentInstance().getExternalContext().getRequestContextPath();
        }
        return basePath;
    }
}

This class contains a so-called Producer Method. As the name suggests, it produces stuff. In this case, it produces a String with Dependent scope. This means the method will be invoked every time the variable is needed. EL expressions or injection are the most common cases for this.

I’m caching the return value, though it’s not necessary, since getting the context path is pretty cheap.

The view could look like this (snippet):

...
<link href="#{basePath}/style/default.css" rel="stylesheet" type="text/css" />
...

Another implementation could put the variable into the Application scope, like this:

public class WebUtils {
    @Produces @Named @ApplicationScoped public String getBasePath() {
        return FacesContext.getCurrentInstance().getExternalContext().getRequestContextPath();
    }
}

As easy it might seem, the approaches shown above require some responsibility from the programmer though. With producer methods, it becomes really easy to mess things up. After all, you’re effectively creating globals. Tool support may help you here though. For example, the Dependency Analyzer in IntelliJ IDEA 9.0.1 already contains pretty decent support for JSF 2.0 and CDI. And, knowing the reputation of the JetBrains folks, I’m sure they come up with even more fancy stuff.

A more classic implementation
A more classic implementation could look like the following:

@Named
@ApplicationScoped
public class WebBean {
    private static volatile String basePath;

    public String getBasePath() {
        if (basePath == null) {
            basePath = FacesContext.getCurrentInstance().getExternalContext().getRequestContextPath();
        }
        return basePath;
    }
}

I’m not using producer methods anymore. The WebBean is now a CDI-managed bean.

The client code becomes slightly more verbose, but who cares? I’ll put the client code in a generic template anyway!:

...
<link href="#{webBean.basePath}/style/default.css" rel="stylesheet" type="text/css" />
...

Wrapping up
I haven’t even showed the complete tip of the iceberg. CDI offers several ways to write code and we’ve yet to find out the (anti) patterns.

I would like to point you to the OpenWebBeans documentation for more info, but unfortunately this is still under development. The good news is that JBoss Weld already has extensive documentation.

On this blog, I’d like to elaborate a bit further on the interesting features JSF 2.0 has to offer.

JSF 2.0: System Events
JSF 2.0 comes with a useful feature, called System events. System events are predefined events that are published at predefined points in the lifecycle.
System events are either global or component system events.

Global system events
An example of a global system event is PostConstructApplicationEvent, which is published when all configuration is done. It can be seen as a JSF replacement for ServletContextListener.

Listener registration is done by invoking Application.subscribeToEvent(Class<? extends SystemEvent> type, SystemEventListener listener).

Component system events
Component system events only apply to the component to which the listener is attached.

An example of a component system event is PreRenderComponentEvent. This event is published to the appropriate component when it’s about to be rendered.

Listener registration is done by invoking UIComponent.subscribeToEvent(Class<? extends SystemEvent> type, ComponentSystemEventListener listener).

<f:event /> tag
The JSF 2.0 spec also defines the <f:event /> tag, which needs to be nested inside a component tag in the web page. This tag is used to make listener registration easier. Just nest the tag inside a component tag in your Facelet, specify the event to listen to and specify a MethodExpression to your listener method and everything works.

An example
Below is an example of an e-banking login page. It uses a challenge-response authentication mechanism, so it generates a “random” challenge when the page is loaded. Because users can navigate to the login page directly (GET-request), we can’t rely on an action method to be invoked first, so let’s fix this using system events.

First, a bit of history
I’ve always hated to write “the first” page in JSF. Since JSF short circuits the lifecycle in the case of a GET request, you don’t really have an appropriate hook for page initialization, making it difficult to create a dynamic landing page.

One could write “lazy getters”:

public class MyBackingBean {
    private List accounts;

    public List getAccounts() { // Yuck
        if (accounts == null) {
            // Do some expensive database query
            accounts = doSomeWork();
        }
        return accounts;
    }
}

It’s quite obvious this is extremely nasty. You don’t know when the getter is invoked (EL triggers the invocation), and that if-null check is also ugly. Btw. getters with logic are ugly anyway…

JSF 1.2 offered a slightly more elegant option with @PostConstruct:

public class MyBackingBean {
    private List accounts;

    @PostConstruct
    public void init() {
        accounts = doSomeWork();
    }

    public List getAccounts() { // Still not good
        return accounts;
    }
}

This is a bit better, but still not very good. The exact point of invocation within the lifecycle is still not obvious. But at least we now know the init() method won’t be invoked multiple times.

There are other ways to tackle this issue, for example, using a PhaseListener, or using a framework like Seam, but that has issues of its own.

Back to the event example
Below is a snippet of my login page.

<h:form>
  <dl>
    <dt><h:outputLabel value="Customer ID" for="customerId" /></dt>
    <dd><h:inputText id="customerId" value="#{loginBean.customerId}" required="true" /></dd>
    <dt><h:outputLabel value="Challenge" for="challenge" /></dt>
    <dd><h:outputText id="challenge" value="#{loginBean.challenge}">
      <f:event name="preRenderComponent" listener="#{loginBean.generateChallenge}" />
    </h:outputText></dd>
    <dt><h:outputLabel value="Response (always 123456)" for="response" /></dt>
    <dd><h:inputSecret id="response" value="#{loginBean.response}" required="true" /></dd>
    <dt> </dt>
    <dd><h:commandButton value="Login" action="#{loginBean.loginUsingTokenGenerator}" /></dd>
  </dl>
</h:form>

As you can see, the above snippet contains the challenge response login form. Line 7 is the interesting one. It registers a PreRenderComponentEvent listener method on the LoginBean.

The LoginBean is shown next (snippet…).

@Named
@SessionScoped
public class LoginBean implements Serializable {
    private Integer customerId;
    private Integer challenge;
    private Integer response;
    private @Inject LoginService loginService;
    private Customer customer;
    // Getters and setters

    public void generateChallenge(ComponentSystemEvent event) throws AbortProcessingException {
        this.challenge = loginService.generateChallenge();
    }

    public String loginUsingTokenGenerator() {
        customer = loginService.loginUsingTokenGenerator(customerId, challenge, response);
        if (customer == null) {
            FacesContext.getCurrentInstance().addMessage(null,
                        new FacesMessage(
                        "Username and/or password is incorrect or your account has been disabled"));
            return null;
        } else {
            return "/pages/homepage.xhtml?faces-redirect=true";
        }
    }
}

Don’t mind the annotations, they come from CDI (JSR-330 a.k.a. Contexts and Dependency Injection). The only thing to remember from these is that this class is a Session scoped managed bean which gets a LoginService injected. Note that I would also prefer ViewScoped, instead of SessionScoped.

Also, don’t mind the return values in loginUsingTokenGenerator. This is also a new feature in JSF 2.0, called Implicit Navigation.

Note the generateChallenge() method. The throws clause is not mandatory. The argument type must be ComponentSystemEvent though.

Wrapping up
As you can see, System events and the <f:event /> tag provide a convenient way to hook in custom logic on a per-component basis.

And, because we’re back to normal OO programming, instead of getter hacking, unit testing the LoginBean is easy as pie!

Pretty neat huh?!

I will therefore share it with you.

The code

Let’s first look a some code dealing with getting the last day of the month:

public class CalendarTest {
  public static void main(String[] args) {
    Calendar c = Calendar.getInstance();
    c.set(Calendar.MONTH, Calendar.FEBRUARY);
    int maxDayOfMonth = c.getActualMaximum(Calendar.DAY_OF_MONTH);

    System.out.println("last day of month = " + maxDayOfMonth);
  }
}

Please read the java doc for Calendar.getActualMaximum():

Returns the maximum value that the specified calendar field could have, given the time value of this Calendar. For example, the actual maximum value of the MONTH field is 12 in some years, and 13 in other years in the Hebrew calendar system.

So the code above can print two different values right …? 28 or 29 depending on the whether this year is a leap year. As you could have guessed that is another unexpected possibility. I can also print 31. Yes… really.

I all depends on the date on which this code is executed.

The problem is that Calendar.getInstance() will return a Calendar filled with the current date/time. Let’s assume the above code runs on the last day of January. The call to getInstance() will return 31-01-2009. The next step puts the month to February. This will result in a overflow as 31-02-2009 is invalid. Because of this Calendar will move the date to 3-03-2000. And March has 31 days.

There is a bug report (status: Closed, Not a Defect) in the SDN which told me that the observed behavior was correct. I was not the first person surprised by this and I’m guessing I will not be the last.

I was …

1. … lucky I wrote a decent unit test.
2. … lucky to be running said unit test om 31 December.
3. … unlucky for having to work on the last day of the year.

Otherwise the bug I created would properly have slipped through the QA cycles and would have ended up in production. There it would only be visible on the last three days of every month if someone would specify a date in February.

What about lenient?
The Calendar.setLenient function does protect against invalid input. Let’s quote the the Calendar java doc about Leniency:

Leniency
Calendar has two modes for interpreting the calendar fields, lenient and non-lenient. When a Calendar is in lenient mode, it accepts a wider range of calendar field values than it produces. When a Calendar recomputes calendar field values for return by get(), all of the calendar fields are normalized. For example, a lenient GregorianCalendar interprets MONTH == JANUARY, DAY_OF_MONTH == 32 as February 1.

When a Calendar is in non-lenient mode, it throws an exception if there is any inconsistency in its calendar fields. For example, a GregorianCalendar always produces DAY_OF_MONTH values between 1 and the length of the month. A non-lenient GregorianCalendar throws an exception upon calculating its time or calendar field values if any out-of-range field value has been set.

So lenient does protect against the programmer/user creating a invalid date in a way that the following code will result in an exception:

    Calendar c = Calendar.getInstance();
    c.setLenient(false);
    c.set(Calendar.MONTH, Calendar.FEBRUARY);
    c.set(Calendar.DAY_OF_MONTH, 31);
    System.out.println(c.getTime());

But the exception is only thrown when c.getTime() is called. Calls to getActualMaximum() still work and return 31. So lenient is not useful here.

Lessons learned

The quick fix for this problem is to set the DAY_OF_MONTH to 1 (or any number between 1 and 28) before setting the month.

I also learned that Calendar.setLenient() will not protect you from this error. It will only stop you from getting an invalid Date. It does not protect against overflows.

Sould I use JODA time?

At the end of this post I have a question for you. I have no experience with JODA time always preferring to use the standard Date/Time API unless there was a problem. But perhaps I should reverse my views and use JODA time unless I’m not allowed too? What do you think … is it time to stop  using the default Calendar API and use JODA time instead? Or should I wait for Java 7 with JSR 310?