Even some of the recent versions of Glassfish include a version of Weld, the reference implementation for CDI (JSR 299), that has some major issues. Since Glassfish uses OSGI, upgrading isn’t as easy as just replacing the jar with a new one. This tutorial shows you how to upgrade Glassfish to Weld 1.0.1.Final as well as including a pre-built distribution of the two files that need re-deploying.

One of the ways to get around the faulty version of Weld currently in Glassfish is to moving up to Glassfish 3.0.1 nightly builds (update : 3.0.1 has been released and should be used) . A less bleeding edge solution would be to upgrade the version of Weld that is deployed on your current version of Glassfish by updating the weld-integration and weld-osgi-bundle jar files. However, one must be careful of the integration jar version as one of the major interfaces changed after the initial release of Weld introducing incompatibilities.

Updating the OSGI bundle is easy since it can be built from the Weld source code. Just download and compile it and locate the osgi-bundle.jar file.

We also need to grab a new version of the weld-integration.jar file. There are all sorts of versions of this file, but the one I found working for Weld 1.0.1.final was version 3.0.1-b11/.

I’ve already built the osgi-bundle and grabbed the integration jar and verified that they work so I’ve renamed and zipped them so you can just download and unzip them into the modules directory of your Glassfish v3 installation.

This is also a necessary step to get the Knappsack Java EE 6 demo project working under Glassfish. You can find more details on the server compatability page

(Edit : I renamed this post so it doesn’t seem like Spigot is just for Seam, Spigot can be used with different frameworks or without any at all. However, I wrote this post since Spigot is so familiar to the Seam EntityQuery that it should be easy for Seam users to get the idea)

Seam developers should become familiar with Spigot concepts fairly quickly since they are very similar to those found in the Seam EntityQuery which was one of the main inspirations for the framework. If you imagine taking the entity query class and splitting it in two, one part to keep hold of state and the other to actually fetch the data. The stateful part is the Paginator that keeps track of what the current ordering of the data is, what is the current page and how big the pages are. The stateless part takes the Ejbql and the pagination information and returns a subset of the data. Now imaging that the data provider has the JPA pieces taken out and replaced with an abstract fetchResults method. This method is implemented in subclasses for specific data providers for text files, sql queries, jpa queries, native jpa queries, xml files, comma delimited or just an in memory dataset.

I also abstracted the concepts of parameterization and parameter resolution so you can have parameters on data providers that are no t query based and your parameters can be resolved using different mechanisms such as EL, reflection, a map, or using custom parameter resolution.
So really, for Seam developers, its like a Seam EntityQuery that doesn’t just use JPA, but uses any kind of data source you want but still returns just a list of objects.

Spigot works nicely with CDI and there is even a demo of it in the distribution that uses JSF and was generated using the Weld maven archetypes. Also, there is a Seam Jpa Dataset Adapter that you can use as a direct replacement for the EntityQuery which will adapt the entity query calls to the underlying data provider calls so you can have a seam-less transition if you want to switch over. This is still a little in-progress, but works. The one area that isn’t implemented is the sorting, which may not be possible, but I still need to add in the methods to the adapter even if they don’t do anything. The other issue is of course the configuration of the query from components.xml using the Seam Framework tags. However, you can define the query using regular component xml tags to define the Ejbql, restrictions and page sizes.

Two things to note if you start using Spigot in place of the entity query. All rows are returned by default, and you need to specify both a select statement and a count statement. I separated those two out so you can put join fetch phrases in the select statement without it breaking the count statement. There is an init method that you can use to set both of these statements for a class type.

It’s been a while since I’ve posted anything new as I’ve been busy with a new Open Source software project called Spigot. It’s a java library that sits between your application code and your data sources (Hibernate, JPA, JDBC or any arbitrary source of data) and helps with things like pagination and sorting using a common interface so you can switch out data providers and use alternatives.

For query language data providers, Spigot also facilitates excluding restrictions from WHERE clauses when parameters are resolved to null. Parameters are handled using parameter resolvers so there is more than one way to parameterize the query including EL expressions, reflection or a value map on the data provider.

Spigot also provides a few other add-ins like converting any dataset into an in-memory dataset that can itself be paginated and sorted and shared across an application (such as commonly used data in a web application). The IndexedDataProviderCache can give you random access into a dataset with caching and look ahead loading. This lets you hook a dataset with thousands of rows up to a Swing JTable with an instant response and a very small memory footprint since it doesn’t need to load all the objects at once as the provider will load the records as needed and cache the results. This is demonstrated in the Swing Demo in the download. There are also demos for Wicket and CDI with JSF.

You can ready about why I created Spigot in the documentation

Spigot is currently hosted on Project Kenai, where you can download the release, view documentation online or read about 10 ways Spigot helps developers.

As a refresher, in our last part, we had an application that obtained a list of items, validated them and took a specific action when an invalid item was found. Lets say in the future we want to expand our system to handle all sorts of things happening when we find an invalid item. This could range from an email being sent, changes made to other data (i.e. an order canceled) or storing a list of rejections in a file or database table. To completely decouple the implementation we can use events. Events are raised by the event producer and subscribed to by event observers. Like most of CDI, event production and subscription is type safe and allows qualifiers to determine which events observers will observe.

Luckily we don’t have to change our application much to implement this, we just provide an implementation of the ItemErrorHandler that raises the event when it handles the item. We will inject an instance of the Item error handler called EventErrorHandler and create a @Notify qualifier to select it for injection.

@Retention(RetentionPolicy.RUNTIME)
@Target({FIELD,METHOD,PARAMETER,TYPE})
@Qualifier
public @interface Notify {}

@Notify
public class EventItemHandler implements ItemErrorHandler {

    @Inject
    private Event<Item> itemEvent;

    public void handleItem(Item item) {
        System.out.println("Firing Event");
        itemEvent.fire(item);
    }
}

In this item handler, we inject an instance of an Event where the event payload will be an Item. The event payload is the state data passed from the event producer to the event observer which in this case passes the rejected Item. When the invalid item is handled, we fire the event and pass in the invalid item we received. This event based item handler is injected the same as any other item handler would be so we can swap it in and out whenever we need to and also can substitute it during testing. We created a @Notify qualifier annotation to identify this error handler for injection and can use it in our item processor by adding it to the injection point.

    @Inject
    @Notify
    private ItemErrorHandler itemErrorHandler;

If we deploy this now, we will see that when the item processor hits invalid items, the event based item error handler fires the event. Currently though we don’t have anything observing the event. We can fix this by creating an observer method which is the only thing needed to observe an event. We can still re-use our existing item processors by adding an event observer method to the implementations which just calls the error handler method. For example, to make our FileErrorReporter respond to the event, we add the following observer event.

public class FileErrorReporter implements ItemErrorHandler,Serializable {

    public void eventFired(@Observes Item item) {
        handleItem(item);
    }
    ....
    ....

If you run the application now, you will see that the events are fired on the invalid objects, and the item information is being saved when this event is fired. You will also note that the lifecycle events are being observed.

INFO: Firing Event
INFO: Creating file error reporter
INFO: Saving eedemo.Item@1f84b46 [Value=34, Limit=7] to file
INFO: Closing file error reporter
INFO: Firing Event
INFO: Creating file error reporter
INFO: Saving eedemo.Item@2656da [Value=89, Limit=32] to file
INFO: Closing file error reporter

Note that the file error reporter bean is created each time the event is raised which may or may not be what we want. In this case, we don’t want to create the bean new each time since we don’t want to open and close the file for each item. We still want to open the file at the start of the process, and then close it once the process it completed. In this case, we need to consider the scope of the FileErrorReporter bean which doesn’t have a scope defined. When no scope is defined, CDI defaults it to the default pseudo dependent scope. What this means in practice is that the bean is created and destroyed over a very short space of time, typically over a method call. In our case here, the bean is created and destroyed for the duration of the event being fired. To fix this, we need to lengthen the scope of the bean by manually adding a scope annotation. We will make this bean @RequestScoped so once the bean is created the first time the event is fired, it will remain created for the duration of the request. Also, for any injection points that this bean is qualified to be injected to, the same bean instance will be injected. Here is the log when we make our scope change to the bean. Note that the bean is still only created when the event is fired.

INFO: Firing Event
INFO: Creating file error reporter
INFO: Saving eedemo.Item@1380c08 [Value=34, Limit=7] to file
INFO: Firing Event
INFO: Saving eedemo.Item@1b44f96 [Value=89, Limit=32] to file
INFO: Closing file error reporter

Let’s take the events example a little further. Right now we are observing any event for an item but chances are, there may be different types of events in the system for the items. We want to be specific in which observers subscribe to which events. Luckily CDI provides for this in a similar manner to how we determine suitable beans for injection points by using typing and qualifiers.

First, lets create a problem for ourselves by firing events off for each item we validate by adding the following code to the item processor.

    @Inject
    private Event<Item> processorEvent;

    public void execute() {
        List<Item> items = itemDao.fetchItems();
        for (Item item : items) {
            processorEvent.fire(item);
            if (!itemValidator.isValid(item)) {
                itemErrorHandler.handleItem(item);
            }
        }
    }

This will fire an event for each item we process, but we don’t want the invalid item handler to subscribe to each of those events. If we do, we will see output like the following :

INFO: Creating eedemo.EventItemHandler_$$_javassist_748
INFO: Creating file error reporter
INFO: Saving eedemo.Item@6d0baf [Value=34, Limit=7] to file
INFO: Creating eedemo.EventItemHandler
INFO: Firing Event
INFO: Saving eedemo.Item@6d0baf [Value=34, Limit=7] to file
INFO: Saving eedemo.Item@1087300 [Value=4, Limit=37] to file
INFO: Saving eedemo.Item@11674c9 [Value=24, Limit=19] to file
INFO: Saving eedemo.Item@de163a [Value=89, Limit=32] to file
INFO: Firing Event
INFO: Saving eedemo.Item@de163a [Value=89, Limit=32] to file
INFO: Closing file error reporter

For each item, the file item handler observer is being called for each item because we aren’t distinguishing the kind of events fired when the item is processed and the kind of event fired when an invalid item is found. To differentiate between them we will create an @Invalidate qualifier to qualify the event for invalid items. This annotation will be placed on the event injection point and also on the observation point method.

@Notify
@RequestScoped
public class EventItemHandler implements ItemErrorHandler {

    @Inject @Invalidated
    private Event<Item> itemEvent;

    public void handleItem(Item item) {
        System.out.println("Firing Event");
        itemEvent.fire(item);
    }
}

@Save
@RequestScoped
public class FileErrorReporter implements ItemErrorHandler,Serializable {

    public void eventFired(@Observes @Invalidated Item item) {
        handleItem(item);
    }

    ....

}

If you run the code now, you will see that we no longer call the file save handler for each item, even though we are firing the event for each item.

INFO: Firing Event
INFO: Creating file error reporter
INFO: Saving eedemo.Item@1e3aa22 [Value=34, Limit=7] to file
INFO: Firing Event
INFO: Saving eedemo.Item@172940f [Value=89, Limit=32] to file
INFO: Closing file error reporter

You can add an event observer to the item processor just to see the events are still being raised and can be observed.

@Named("itemProcessor")
@RequestScoped
public class ItemProcessor {

    ....

    public void observeItemEvent(@Observes Item item) {
        System.out.println("Item event observed for item "+item);
    }
}

This will print a message whenever an event is fired so you can see that there is a difference between the two event subscribers and also that the more general version of the observer sees all events related to the item.

Events are a great way to decouple parts of the system in a modular fashion as you can add pieces that will subscribe to events with the event producer unaware of the observer as opposed to the even producer having to call the observer manually when events are not used. For example, if someone updates an order status, you could add events to email the sales rep, or notify an account manager if a tech support issue is open for more than a week. These kinds of rules can be implemented without events, but events make it easier to decouple the business logic. Additionally, there is no compile or build time dependency and you can just add modules to your application and they will automatically start observing and producing events. Additionally, observers and producers know nothing about each other, nor do they require any configuration for them to do so.

Scheduling the Processing

One last tidbit before we move on to creating CDI driven JSF apps is that for now we are running our code from a button in a JSF page but typically this is something that would get fired off on a regular basis. With the power of the EJB 3.1 scheduler we can do just that in a new class with few lines of code. We’ll create a new stateless EJB into which we’ll inject our ItemProcessor and add a method to call the execute() method which will be called at a scheduled time.

@Stateless
public class ScheduledProcessor {

    @Inject
    private ItemProcessor itemProcessor;

    @Schedule(hour="07",minute = "00")
    public void execute() {
        System.out.println("executing scheduled job!");
        itemProcessor.execute();
    }
}

This makes use of the new EJB 3.1 @Schedule annotation and will schedule this method to be called every morning at 7am. You could make it on the hour every hour, or you could use the EJB timer service to implement your own timeout. We inject the same ItemProcessor implementation we have been using all along and call the execute() method. That is a pretty powerful transformation letting us re-use our existing code and easily incorporating EJB services with POJO managed beans into an EJB needing only a few lines of code.

Note : If you actually implement this and run it, it won’t work because of a Weld 1.0 bug whereby the request scope isn’t active during calls to EJB timeouts (see here for details) so you’ll have to wait until Weld 1.01 which should be out fairly soon.

Last Time

Last time we looked at setting up the development environment and creating our EE6 application in Netbeans and deploying it to Glassfish v3. This time, we’ll skip straight to writing code which can be put into either a new Netbeans project using the previous tutorial, or you can use the existing project and just add the new code.

The ‘I’ in CDI

CDI is an API for injecting contexts and dependencies which is the part we’ll turn our attention to now. In Seam and Spring dependencies worked mostly by naming beans and binding them to their injection points by their name. So far we have only referenced a managed bean by name from the JSF page when we defined the name for the bean using the @Named annotation. The primary role of the @Named annotation is to define the bean for the purpose of resolving EL statements within the application, usually through the JSF EL resolvers. Injection could be performed by using names, but this was not how injection in CDI was meant to work since CDI gives us a much richer way to express injection points and the beans to be injected into them.

Let’s look at an example which is somewhat contrived. We have a dao that returns a list of objects that need validating, and for invalid ones, we take a certain action. Here’s the definition for the item.

package eedemo;

public class Item {

    private int value;
    private int limit;

    @Override
    public String toString() {
        return super.toString() + String.format(" [Value=%d, Limit=%d]", value,limit);
    }

    /*
    getters and setters omitted
    */
}

The ItemDao interface defines how we get the list of item objects. In this test application we anticipate using multiple implementations so we will code to interfaces.

public interface ItemDao {

    List<Item> fetchItems();

}

The ItemProcessor is our main class that we will inject our beans into and execute the process from. For now, we will start with the Dao and look at how we will inject it into our processor bean.

import java.util.List;
import javax.inject.Named;
import javax.enterprise.context.RequestScoped;

@Named("itemProcessor")
@RequestScoped
public class ItemProcessor {

    private ItemDao itemDao;

    public void execute() {
      List<Item>  items = itemDao.fetchItems();
      for (Item item : items) {
          System.out.println("Found item "+item);
      }
    }
}

We’ll start with a simple Dao that just creates a list of items and returns a fixed list of items.

public class DefaultItemDao implements ItemDao {

    public List<Item> fetchItems() {
        List<Item> results = new ArrayList<Item>();
        results.add(new Item(34, 7));
        results.add(new Item(4, 37));
        results.add(new Item(24, 19));
        results.add(new Item(89, 32));
        return results;
    }
}

In order to inject the DefaultItemDao into our ItemProcessor we add the javax.inject.Inject annotation to the ItemDao field to indicate that this field is an injection point.

@Named("itemProcessor")
@RequestScoped
public class ItemProcessor {

    @Inject
    private ItemDao itemDao;

    ...
}

Finally, we need some way to call the execute()ItemProcessor. We can run this in a SE environment, but for now we’ll keep it in a JSF page. We’ll add a new page with a button to call the execute method called process.xhtml.

<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:h="http://java.sun.com/jsf/html">
    <h:head>
        <title>Item Processor</title>
    </h:head>
    <h:body>
        <h:form>
        <h:commandButton action="#{itemProcessor.execute}" value="Execute"/><br/>
        </h:form>
    </h:body>
</html>

If you open up the page at http://localhost:8080/ee6demo/faces/process.xhtml you will see just a button that when clicked lists the items from our default Dao implementation in the console.

INFO: Found item eedemo.Item@23cbc6 [Value=34, Limit=7]
INFO: Found item eedemo.Item@a40279 [Value=4, Limit=37]
INFO: Found item eedemo.Item@19e6292 [Value=24, Limit=19]
INFO: Found item eedemo.Item@1597bc4 [Value=89, Limit=32]

We created a class which implements the ItemDao interface and when the application was deployed our managed beans in the module were processed by the CDI implementation (again because of the beans.xml file in the module. Our Inject annotation specifies that we want to inject a managed bean into that field and the only thing we know about the bean to inject is that it must implement ItemDao or some subtype of that interface. In this case, the DefaultItemDao class fits the bill perfectly.

Let’s say we add another Dao class to our application which also implements the ItemDao interface, now the choice isn’t so clear as to which bean we want to inject.

public class AnotherItemDao implements ItemDao {

    public List<Item> fetchItems() {
        List<Item> results = new ArrayList<Item>();
        results.add(new Item(99, 9));
        return results;
    }

}

We now have two classes the implement this interface and predictably, Weld gives us an ambiguous dependency error meaning that it cannot determine what bean to use for that injection point. Most, if not all of the errors that can occur with regards to CDI injection in Weld are reported at deployment time, even down to whether beans are missing a Serializable implementation.

Caused by: org.jboss.weld.DeploymentException: Injection point has ambiguous dependencies.
Injection point: field eedemo.ItemProcessor.itemDao; Qualifiers: [@javax.enterprise.inject.Default()]; 

Possible dependencies: [eedemo.AnotherItemDao, eedemo.DefaultItemDao]

We could make our itemDao field in the item processor a type that matches one of the implementation types (AnotherItemDao or DefaultItemDao) since it would then match one and only one class type. However, then we would lose the benefits of coding to an interface and find it harder to change implementations without changing the field type. A better solution is to instead look at CDI Qualifiers.

Qualifiers

A CDI qualifier is an annotation that can be applied at the class level to indicate the kind of bean the class is, and also at the field level (among other places) to indicate what kind of bean needs to be injected at that point.

When CDI inspects an injection point to find a suitable bean to inject it takes not only the class type into account, but also any qualifiers. Without knowing it, we have already used one qualifier which is the default qualifier called @Any. Let’s create a @Demo qualifier which we can apply to our DefaultItemDao implementation and also to the injection point.

package eedemo.qualifier;

import static java.lang.annotation.ElementType.TYPE;
import static java.lang.annotation.ElementType.FIELD;
import static java.lang.annotation.ElementType.PARAMETER;
import static java.lang.annotation.ElementType.METHOD;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;
import javax.inject.Qualifier;

@Retention(RetentionPolicy.RUNTIME)
@Target({FIELD,METHOD,PARAMETER,TYPE})
@Qualifier
public @interface Demo {

}

First, we’ll add this qualifier to our default dao implementation at the class level.

@Demo
public class DefaultItemDao implements SomeDao {

    public List<Item> fetchItems() {
..
..

If you save and deploy this file now, you may notice that we don’t have any errors, and if you go to the web page and click the execute button, you can see that in the console, it displays the list of items from the AnotherItemDao dao (remember we annotated the DefaultItemDao implementation but not the injection point). By adding the Demo qualifier to the default dao implementation, we made the other implementation a more suitable match for the injection point as it matched on type and on qualifiers and the DefaultItemDao has a qualifier that is not on the injection point making it less suitable.

If we add the Demo annotation to the injection point and deploy it, when we click our button we use the default implementation again. This is because we are matching based on type and qualifiers and the DefaultItemDao is the only bean with both the correct type and the Demo annotation.

Alternative Injection Methods

There are multiple ways to define an injection point on the injected class. So far we have annotated the fields that will reference the injected object. You do not need to provide getters and setters for field injection. If we wish to create immutable managed beans with final fields, we can use injection in the constructor by annotating the constructor with the Inject annotation. We can then apply any annotations to constructor parameters to qualify beans for injection (of course, each parameter has a type that can assist in qualifying beans for injection). A bean may only have one constructor with injection points defined, but it may implement more than one constructor.

@Named("itemProcessor")
@RequestScoped
public class ItemProcessor {

    private final ItemDao itemDao;

    @Inject
    public ItemProcessor(@Demo ItemDao itemDao) {
        this.itemDao = itemDao;
    }
}

We can also call an inialization method which can be passed the beans to be injected.

@Named("itemProcessor")
@RequestScoped
public class ItemProcessor {

    private ItemDao itemDao;

    @Inject
    public void setItemDao(@Demo ItemDao itemDao) {
        this.itemDao = itemDao;
    }
}

While in the above case we used the setter method for initialization we can create any method and use it for initialization with as many beans as we want in the method call. We can also have multiple initialization methods in a bean.

    @Inject
    public void initBeans(@Demo ItemDao itemDao,@SomeQualifier SomeType someBean) {
        this.itemDao = itemDao;
        this.bean = someBean;
    }

The same rules apply to bean matching regardless of how the injection point is defined, it will try and find the best match based on type and qualifiers and will fail on deployment if there are multiple matching beans or no matching beans for an injection point.

Let’s look at the other aspects of our application, we get a list of items, iterate through them and test each one and if it fails that test, we pass it on to an error handler. We’ll create an ItemValidator interface to determines whether an item is valid or not.

public interface ItemValidator {
    boolean isValid(Item item);
}

We’ll expand our ItemProcessor class to incorporate the new feature.

@Named("itemProcessor")
@RequestScoped
public class ItemProcessor {

    @Inject @Demo
    private ItemDao itemDao;

    @Inject
    private ItemValidator itemValidator;

    public void execute() {
      List<Item>  items = itemDao.fetchItems();
      for (Item item : items) {
          System.out.println("Item = "+item+" valid = "+itemValidator.isValid(item));
      }
    }
}

Our first implementation will be DefaultItemValidator which will simply test the limit against the value.

public class DefaultItemValidator implements ItemValidator {

    public boolean isValid(Item item) {
        return item.getValue() < item.getLimit();
    }
}

If we save our changes, go to our web page and click our button, in the console you will see that our items are being validated and the only valid item is where the value is less than the limit.

INFO: Item = eedemo.Item@25dd89 [Value=34, Limit=7] valid = false
INFO: Item = eedemo.Item@1f37ca2 [Value=4, Limit=37] valid = true
INFO: Item = eedemo.Item@7b8d67 [Value=24, Limit=19] valid = false
INFO: Item = eedemo.Item@18075da [Value=89, Limit=32] valid = false

Now lets consider the scenario where we have a deployment to a different site that is more relaxed and considers an item invalid only if the value is more than twice the limit. We may want to have another bean that implements the validator interface for that logic.

public class RelaxedItemValidator implements ItemValidator {

    public boolean isValid(Item item) {
        return item.getValue() < (item.getLimit() * 2);
    }
}

Now we have an ambiguous dependency problem since we have two classes implementing the same interface. The only difference is based on deployment so for most deployments, we want to use the default, but for one deployment, we want to use the relaxed implementation. CDI offers the use of the Alternative annotation which lets you package multiple beans that match an injection point without ambiguity errors, and the bean to use is defined in the beans.xml. This means you can deploy both implementations in the same module with the only difference being the beans.xml definition which can change over different deployments.

@Alternative
public class DefaultItemValidator implements ItemValidator {

    public boolean isValid(Item item) {
        return item.getValue() < item.getLimit();
    }
}

and

@Alternative
public class RelaxedItemValidator implements ItemValidator {

    public boolean isValid(Item item) {
        return item.getValue() < (item.getLimit() * 2);
    }
}

If we deploy our application now, we will get an unsatisfied dependency error since we defined the two matching beans as alternative but we didn’t enable either of them in the beans.xml file.

<beans
    xmlns="http://java.sun.com/xml/ns/javaee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="

http://java.sun.com/xml/ns/javaee

http://java.sun.com/xml/ns/javaee/beans_1_0.xsd">

    <alternatives>
        <class>eedemo.RelaxedItemValidator</class>
    </alternatives>
</beans>

This tells CDI that for this deployment we want to use the RelaxedItemValidator. You can think of the alternative annotation as effectively disabling the bean making it unavailable for injection, but allowing the implementation to be packaged with the other beans. Adding it as an alternative in the beans.xml file effectively enables the bean making it available for injection. By moving this type of metadata to the beans.xml file, we can bundle different versions of the file with different deployments.

Handling Invalid Items

Continuing the example, invalid items are sent to the ItemErrorHandler as they are discovered.

public interface ItemErrorHandler {
    void handleItem(Item item);
}

Let’s start by implementing a fake handler that saves the item details to a file. We want to open the file before we start handling items, leave it open for the duration of the process as we add content to the file, and then close the file when we are done with our processing. We could manually add initProcess() and finishProcess() methods to the error reporter bean, but then we couldn’t code to the interface since the caller would need to know about those class specific methods. We could add those same methods to the ItemErrorReporter interface but then we would have to unnecessarily implement those methods in every class that implements that interface. Instead, we can use some of the lifecycle annotations from the Managed Bean spec to call methods on the bean at certain points in the bean lifecycle. A PostConstruct annotated method is called when the bean has been constructed and any dependencies the bean has have been injected. Likewise, a PreDestroy annotated method is called just before the bean is disposed of by the container.

public class FileErrorReporter implements ItemErrorHandler {

    @PostConstruct
    public void init() {
        System.out.println("Creating file error reporter");
    }

 @PreDestroy
    public void release() {
        System.out.println("Closing file error reporter");
    }

    public void handleItem(Item item) {
        System.out.println("Saving "+item+" to file");
    }
}

Our final change is to add the item error handling into our ItemProcessor bean.

@Named("itemProcessor")
@RequestScoped
public class ItemProcessor {

    @Inject @Demo
    private ItemDao itemDao;

    @Inject
    private ItemValidator itemValidator;

    @Inject
    private ItemErrorHandler itemErrorHandler;

    public void execute() {
      List<Item>  items = itemDao.fetchItems();
      for (Item item : items) {
          if (!itemValidator.isValid(item)) {
              itemErrorHandler.handleItem(item);
          }
      }
    }
}

When we run this from our browser we see the following in the console ;

INFO: Creating file error reporter
INFO: Saving eedemo.Item@d8b01e [Value=34, Limit=7] to file
INFO: Saving eedemo.Item@12a5e8 [Value=89, Limit=32] to file
INFO: Closing file error reporter

Next Time

Different application deployments might use different rules for handling invalid items. such as rejecting the item, to sending notifications to individuals or just flagging them or listing them in an output file. In addition, we may want to do a combination of these (reject an order, send email to the sales rep, and list it in a file).
One great way to handle this kind of multi-faceted problem is using events which we’ll look at next time.

Click to view getting started with jsf 2.0 and CDI 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