Chapter 1. Seam Tutorial

Seam provides a number of example applications demonstrating how to use the various features of Seam. This tutorial will guide you through a few of those examples to help you get started learning Seam. The Seam examples are located in the examples subdirectory of the Seam distribution. The registration example, which will be the first example we look at, is in the examples/registration directory.

Each example has the same directory structure:

The view directory contains view-related files such as web page templates, images and stylesheets.
The resources directory contains deployment descriptors and other configuration files.
The src directory contains the application source code.

The example applications run both on JBoss AS and Tomcat with no additional configuration. The following sections will explain the procedure in both cases. Note that all the examples are built and run from the Ant build.xml, so you'll need a recent version of Ant installed before you get started.

1.1.1. Running the examples on JBoss AS

The examples are configured for use on JBoss AS 4.2 or 5.0. You'll need to set jboss.home, in the shared build.properties file in the root folder of your Seam installation, to the location of your JBoss AS installation.

Once you've set the location of JBoss AS and started the application server, you can build and deploy any example by typing ant explode in the the directory for that example. Any example that is packaged as an EAR deploys to a URL like /seam-example, where example is the name of the example folder, with one exception. If the example folder begins with seam, the prefix "seam" is ommitted. For instance, if JBoss AS is running on port 8080, the URL for the registration example is http://localhost:8080/seam-registration/, whereas the URL for the seamspace example is http://localhost:8080/seam-space/.

If, on the other hand, the example gets packaged as a WAR, then it deploys to a URL like /jboss-seam-example. Most of the examples can be deployed as a WAR to Tomcat with Embedded JBoss by typing ant tomcat.deploy. Several of the examples can only be deployed as a WAR. Those examples are groovybooking, hibernate, jpa, and spring.

1.1.2. Running the examples on Tomcat

The examples are also configured for use on Tomcat 6.0. You will need to follow the instructions in Section 30.6.1, “Installing Embedded JBoss” for installing JBoss Embedded on Tomcat 6.0. JBoss Embedded is only required to run the Seam demos that use EJB3 components on Tomcat. There are also examples of non-EJB3 applications that can be run on Tomcat without the use of JBoss Embedded.

You'll need to set tomcat.home, in the shared build.properties file in the root folder of your Seam installation, to the location of your Tomcat installation. make sure you set the location of your Tomcat.

You'll need to use a different Ant target when using Tomcat. Use ant tomcat.deploy in example subdirectory to build and deploy any example for Tomcat.

On Tomcat, the examples deploy to URLs like /jboss-seam-example, so for the registration example the URL would be http://localhost:8080/jboss-seam-registration/. The same is true for examples that deploy as a WAR, as mentioned in the previous section.

1.1.3. Running the example tests

Most of the examples come with a suite of TestNG integration tests. The easiest way to run the tests is to run ant test. It is also possible to run the tests inside your IDE using the TestNG plugin. Consult the readme.txt in the examples directory of the Seam distribution for more information.

1.2. Your first Seam application: the registration example

The registration example is a simple application that lets a new user store his username, real name and password in the database. The example isn't intended to show off all of the cool functionality of Seam. However, it demonstrates the use of an EJB3 session bean as a JSF action listener, and basic configuration of Seam.

We'll go slowly, since we realize you might not yet be familiar with EJB 3.0.

The start page displays a very basic form with three input fields. Try filling them in and then submitting the form. This will save a user object in the database.

1.2.1. Understanding the code

The example is implemented with two Facelets templates, one entity bean and one stateless session bean. Let's take a look at the code, starting from the "bottom".

1.2.1.1. The entity bean: `User.java`

We need an EJB entity bean for user data. This class defines persistence and validation declaratively, via annotations. It also needs some extra annotations that define the class as a Seam component.

Example 1.1. User.java

@Entity

@Name("user")

@Scope(SESSION)

@Table(name="users")

public class User implements Serializable

{

   private static final long serialVersionUID = 1881413500711441951L;

   

   private String username;

   private String password;

   private String name;

   

   public User(String name, String password, String username)

   {

      this.name = name;

      this.password = password;

      this.username = username;

   }

   

   public User() {}

   

   @NotNull @Length(min=5, max=15)

   public String getPassword()

   {

      return password;

   }


   public void setPassword(String password)

   {

      this.password = password;

   }

   

   @NotNull

   public String getName()

   {

      return name;

   }


   public void setName(String name)

   {

      this.name = name;

   }

   

   @Id @NotNull @Length(min=5, max=15)

   public String getUsername()

   {

      return username;

   }


   public void setUsername(String username)

   {

      this.username = username;

   }


}

	The EJB3 standard `@Entity` annotation indicates that the `User` class is an entity bean.
	A Seam component needs a component name specified by the `@Name` annotation. This name must be unique within the Seam application. When JSF asks Seam to resolve a context variable with a name that is the same as a Seam component name, and the context variable is currently undefined (null), Seam will instantiate that component, and bind the new instance to the context variable. In this case, Seam will instantiate a `User` the first time JSF encounters a variable named `user`.
	Whenever Seam instantiates a component, it binds the new instance to a context variable in the component's default context. The default context is specified using the `@Scope` annotation. The `User` bean is a session scoped component.
	The EJB standard `@Table` annotation indicates that the `User` class is mapped to the `users` table.
	`name`, `password` and `username` are the persistent attributes of the entity bean. All of our persistent attributes define accessor methods. These are needed when this component is used by JSF in the render response and update model values phases.
	An empty constructor is both required by both the EJB specification and by Seam.
	The `@NotNull` and `@Length` annotations are part of the Hibernate Validator framework. Seam integrates Hibernate Validator and lets you use it for data validation (even if you are not using Hibernate for persistence).
	The EJB standard `@Id` annotation indicates the primary key attribute of the entity bean.

The most important things to notice in this example are the @Name and @Scope annotations. These annotations establish that this class is a Seam component.

We'll see below that the properties of our User class are bound directly to JSF components and are populated by JSF during the update model values phase. We don't need any tedious glue code to copy data back and forth between the JSP pages and the entity bean domain model.

However, entity beans shouldn't do transaction management or database access. So we can't use this component as a JSF action listener. For that we need a session bean.

1.2.1.2. The stateless session bean class: `RegisterAction.java`

Most Seam application use session beans as JSF action listeners (you can use JavaBeans instead if you like).

We have exactly one JSF action in our application, and one session bean method attached to it. In this case, we'll use a stateless session bean, since all the state associated with our action is held by the User bean.

This is the only really interesting code in the example!

Example 1.2. RegisterAction.java

@Stateless    
@Name("register")
public class RegisterAction implements Register
{
   @In
   private User user;
   
   @PersistenceContext
   private EntityManager em;
   
   @Logger
   private Log log;
   
   public String register()
   {          
      List existing = em.createQuery(
         "select username from User where username = #{user.username}")
         .getResultList();
         
      if (existing.size()==0)
      {
         em.persist(user);
         log.info("Registered new user #{user.username}");
         return "/registered.xhtml";
      }       
      else
      {
         FacesMessages.instance().add("User #{user.username} already exists");
         return null;
      }
   }

}

	The EJB `@Stateless` annotation marks this class as a stateless session bean.
	The `@In` annotation marks an attribute of the bean as injected by Seam. In this case, the attribute is injected from a context variable named `user` (the instance variable name).
	The EJB standard `@PersistenceContext` annotation is used to inject the EJB3 entity manager.
	The Seam `@Logger` annotation is used to inject the component's `Log` instance.
	The action listener method uses the standard EJB3 `EntityManager` API to interact with the database, and returns the JSF outcome. Note that, since this is a session bean, a transaction is automatically begun when the `register()` method is called, and committed when it completes.
	Notice that Seam lets you use a JSF EL expression inside EJB-QL. Under the covers, this results in an ordinary JPA `setParameter()` call on the standard JPA `Query` object. Nice, huh?
	The `Log` API lets us easily display templated log messages which can also make use of JSF EL expressions.
	JSF action listener methods return a string-valued outcome that determines what page will be displayed next. A null outcome (or a void action listener method) redisplays the previous page. In plain JSF, it is normal to always use a JSF navigation rule to determine the JSF view id from the outcome. For complex application this indirection is useful and a good practice. However, for very simple examples like this one, Seam lets you use the JSF view id as the outcome, eliminating the requirement for a navigation rule. Note that when you use a view id as an outcome, Seam always performs a browser redirect.
	Seam provides a number of built-in components to help solve common problems. The `FacesMessages` component makes it easy to display templated error or success messages. (As of Seam 2.1, you can use `StatusMessages` instead to remove the semantic dependency on JSF). Built-in Seam components may be obtained by injection, or by calling the `instance()` method on the class of the built-in component.

Note that we did not explicitly specify a @Scope this time. Each Seam component type has a default scope if not explicitly specified. For stateless session beans, the default scope is the stateless context, which is the only sensible value.

Our session bean action listener performs the business and persistence logic for our mini-application. In more complex applications, we might need require a separate service layer. This is easy to achieve with Seam, but it's overkill for most web applications. Seam does not force you into any particular strategy for application layering, allowing your application to be as simple, or as complex, as you want.

Note that in this simple application, we've actually made it far more complex than it needs to be. If we had used the Seam application framework controllers, we would have eliminated all of our application code. However, then we wouldn't have had much of an application to explain.

1.2.1.3. The session bean local interface: `Register.java`

Naturally, our session bean needs a local interface.

Example 1.3. Register.java

@Local

public interface Register

{

   public String register();

}

That's the end of the Java code. Now we'll look at the view.

1.2.1.4. The view: `register.xhtml` and `registered.xhtml`

The view pages for a Seam application could be implemented using any technology that supports JSF. In this example we use Facelets, because we think it's better than JSP.

Example 1.4. register.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:s="http://jboss.com/products/seam/taglib"

    xmlns:h="http://java.sun.com/jsf/html"

    xmlns:f="http://java.sun.com/jsf/core">



   <head>

      <title>Register New User</title>

   </head>

   <body>

      <f:view>

         <h:form>

            <s:validateAll>

               <h:panelGrid columns="2">

                  Username: <h:inputText value="#{user.username}" required="true"/>

                  Real Name: <h:inputText value="#{user.name}" required="true"/>

                  Password: <h:inputSecret value="#{user.password}" required="true"/>

               </h:panelGrid>

            </s:validateAll>

            <h:messages/>

            <h:commandButton value="Register" action="#{register.register}"/>

         </h:form>

      </f:view>

   </body>



</html>

The only thing here that is specific to Seam is the <s:validateAll> tag. This JSF component tells JSF to validate all the contained input fields against the Hibernate Validator annotations specified on the entity bean.

Example 1.5. registered.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:f="http://java.sun.com/jsf/core">



    <head>

        <title>Successfully Registered New User</title>

    </head>

    <body>

        <f:view>

            Welcome, #{user.name}, you are successfully registered as #{user.username}.

        </f:view>

    </body>



</html>

This is a simple Facelets page using some inline EL. There's nothing specific to Seam here.

1.2.1.5. The Seam component deployment descriptor: `components.xml`

Since this is the first Seam app we've seen, we'll take a look at the deployment descriptors. Before we get into them, it is worth noting that Seam strongly values minimal configuration. These configuration files will be created for you when you create a Seam application. You'll never need to touch most of these files. We're presenting them now only to help you understand what all the pieces in the example are doing.

If you've used many Java frameworks before, you'll be used to having to declare all your component classes in some kind of XML file that gradually grows more and more unmanageable as your project matures. You'll be relieved to know that Seam does not require that application components be accompanied by XML. Most Seam applications require a very small amount of XML that does not grow very much as the project gets bigger.

Nevertheless, it is often useful to be able to provide for some external configuration of some components (particularly the components built in to Seam). You have a couple of options here, but the most flexible option is to provide this configuration in a file called components.xml, located in the WEB-INF directory. We'll use the components.xml file to tell Seam how to find our EJB components in JNDI:

Example 1.6. components.xml


<?xml version="1.0" encoding="UTF-8"?>

<components xmlns="http://jboss.com/products/seam/components"

    xmlns:core="http://jboss.com/products/seam/core"

    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

    xsi:schemaLocation="

        http://jboss.com/products/seam/core

        http://jboss.com/products/seam/core-2.1.xsd 

        http://jboss.com/products/seam/components

        http://jboss.com/products/seam/components-2.1.xsd">

            

    <core:init jndi-pattern="@jndiPattern@"/>

     

</components>

This code configures a property named jndiPattern of a built-in Seam component named org.jboss.seam.core.init. The funny @ symbols are there because our Ant build script puts the correct JNDI pattern in when we deploy the application, which it reads from the components.properties file. You learn more about how this process works in Section 5.2, “Configuring components via components.xml”.

1.2.1.6. The web deployment description: `web.xml`

The presentation layer for our mini-application will be deployed in a WAR. So we'll need a web deployment descriptor.

Example 1.7. web.xml


<?xml version="1.0" encoding="UTF-8"?>

<web-app 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/web-app_2_5.xsd"

    version="2.5">



    <listener>

        <listener-class>org.jboss.seam.servlet.SeamListener</listener-class>

    </listener>

    

    <context-param>

        <param-name>javax.faces.DEFAULT_SUFFIX</param-name>

        <param-value>.xhtml</param-value>

    </context-param>

              

    <servlet>

        <servlet-name>Faces Servlet</servlet-name>

        <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>

        <load-on-startup>1</load-on-startup>

    </servlet>



    <servlet-mapping>

        <servlet-name>Faces Servlet</servlet-name>

        <url-pattern>*.seam</url-pattern>

    </servlet-mapping>

              

    <session-config>

        <session-timeout>10</session-timeout>

    </session-config>



</web-app>

This web.xml file configures Seam and JSF. The configuration you see here is pretty much identical in all Seam applications.

1.2.1.7. The JSF configration: `faces-config.xml`

Most Seam applications use JSF views as the presentation layer. So usually we'll need faces-config.xml. In our case, we are going to use Facelets for defining our views, so we need to tell JSF to use Facelets as its templating engine.

Example 1.8. faces-config.xml


<?xml version="1.0" encoding="UTF-8"?>

<faces-config 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/web-facesconfig_1_2.xsd"

    version="1.2">



    <application>

        <view-handler>com.sun.facelets.FaceletViewHandler</view-handler>

    </application>

    

</faces-config>

Note that we don't need any JSF managed bean declarations! Our managed beans are annotated Seam components. In Seam applications, the faces-config.xml is used much less often than in plain JSF. Here, we are simply using it to enable Facelets as the view handler instead of JSP.

In fact, once you have all the basic descriptors set up, the only XML you need to write as you add new functionality to a Seam application is orchestration: navigation rules or jBPM process definitions. Seam's stand is that process flow and configuration data are the only things that truly belong in XML.

In this simple example, we don't even need a navigation rule, since we decided to embed the view id in our action code.

1.2.1.8. The EJB deployment descriptor: `ejb-jar.xml`

The ejb-jar.xml file integrates Seam with EJB3, by attaching the SeamInterceptor to all session beans in the archive.


<?xml version="1.0" encoding="UTF-8"?>

<ejb-jar 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/ejb-jar_3_0.xsd"

    version="3.0">

         

    <interceptors>

        <interceptor>

            <interceptor-class>org.jboss.seam.ejb.SeamInterceptor</interceptor-class>

        </interceptor>

    </interceptors>

   

    <assembly-descriptor>

        <interceptor-binding>

            <ejb-name>*</ejb-name>

            <interceptor-class>org.jboss.seam.ejb.SeamInterceptor</interceptor-class>

        </interceptor-binding>

    </assembly-descriptor>

   

</ejb-jar>

1.2.1.9. The EJB persistence deployment descriptor: `persistence.xml`

The persistence.xml file tells the EJB persistence provider where to find the datasource, and contains some vendor-specific settings. In this case, enables automatic schema export at startup time.


<?xml version="1.0" encoding="UTF-8"?>

<persistence xmlns="http://java.sun.com/xml/ns/persistence" 

    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

    xsi:schemaLocation="

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

        http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd" 

    version="1.0">



    <persistence-unit name="userDatabase">

        <provider>org.hibernate.ejb.HibernatePersistence</provider>

        <jta-data-source>java:/DefaultDS</jta-data-source>

        <properties>

            <property name="hibernate.hbm2ddl.auto" value="create-drop"/>

        </properties>

    </persistence-unit>

    

</persistence>

1.2.1.10. The EAR deployment descriptor: `application.xml`

Finally, since our application is deployed as an EAR, we need a deployment descriptor there, too.

Example 1.9. registration application


<?xml version="1.0" encoding="UTF-8"?>

<application 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/application_5.xsd"

    version="5">

             

    <display-name>Seam Registration</display-name>



    <module>

        <web>

            <web-uri>jboss-seam-registration.war</web-uri>

            <context-root>/seam-registration</context-root>

        </web>

    </module>

    <module>

        <ejb>jboss-seam-registration.jar</ejb>

    </module>

    <module>

        <ejb>jboss-seam.jar</ejb>

    </module>

    <module>

        <java>jboss-el.jar</java>

    </module>



</application>

This deployment descriptor links modules in the enterprise archive and binds the web application to the context root /seam-registration.

We've now seen all the files in the entire application!

1.2.2. How it works

When the form is submitted, JSF asks Seam to resolve the variable named user. Since there is no value already bound to that name (in any Seam context), Seam instantiates the user component, and returns the resulting User entity bean instance to JSF after storing it in the Seam session context.

The form input values are now validated against the Hibernate Validator constraints specified on the User entity. If the constraints are violated, JSF redisplays the page. Otherwise, JSF binds the form input values to properties of the User entity bean.

Next, JSF asks Seam to resolve the variable named register. Seam uses the JNDI pattern mentioned earlier to locate the stateless session bean, wraps it as a Seam component, and returns it. Seam then presents this component to JSF and JSF invokes the register() action listener method.

But Seam is not done yet. Seam intercepts the method call and injects the User entity from the Seam session context, before allowing the invocation to continue.

The register() method checks if a user with the entered username already exists. If so, an error message is queued with the FacesMessages component, and a null outcome is returned, causing a page redisplay. The FacesMessages component interpolates the JSF expression embedded in the message string and adds a JSF FacesMessage to the view.

If no user with that username exists, the "/registered.xhtml" outcome triggers a browser redirect to the registered.xhtml page. When JSF comes to render the page, it asks Seam to resolve the variable named user and uses property values of the returned User entity from Seam's session scope.

1.3. Clickable lists in Seam: the messages example

Clickable lists of database search results are such an important part of any online application that Seam provides special functionality on top of JSF to make it easier to query data using EJB-QL or HQL and display it as a clickable list using a JSF <h:dataTable>. The messages example demonstrates this functionality.

1.3.1. Understanding the code

The message list example has one entity bean, Message, one session bean, MessageListBean and one JSP.

1.3.1.1. The entity bean: `Message.java`

The Message entity defines the title, text, date and time of a message, and a flag indicating whether the message has been read:

Example 1.10. Message.java

@Entity

@Name("message")

@Scope(EVENT)

public class Message implements Serializable

{

   private Long id;

   private String title;

   private String text;

   private boolean read;

   private Date datetime;

   

   @Id @GeneratedValue

   public Long getId()

   {

      return id;

   }

   public void setId(Long id)

   {

      this.id = id;

   }

   

   @NotNull @Length(max=100)

   public String getTitle()

   {

      return title;

   }

   public void setTitle(String title)

   {

      this.title = title;

   }

   

   @NotNull @Lob

   public String getText()

   {

      return text;

   }

   public void setText(String text)

   {

      this.text = text;

   }

   

   @NotNull

   public boolean isRead()

   {

      return read;

   }

   public void setRead(boolean read)

   {

      this.read = read;

   }

   

   @NotNull 

   @Basic @Temporal(TemporalType.TIMESTAMP)

   public Date getDatetime()

   {

      return datetime;

   }

   public void setDatetime(Date datetime)

   {

      this.datetime = datetime;

   }

   

}

1.3.1.2. The stateful session bean: `MessageManagerBean.java`

Just like in the previous example, we have a session bean, MessageManagerBean, which defines the action listener methods for the two buttons on our form. One of the buttons selects a message from the list, and displays that message. The other button deletes a message. So far, this is not so different to the previous example.

But MessageManagerBean is also responsible for fetching the list of messages the first time we navigate to the message list page. There are various ways the user could navigate to the page, and not all of them are preceded by a JSF action — the user might have bookmarked the page, for example. So the job of fetching the message list takes place in a Seam factory method, instead of in an action listener method.

We want to cache the list of messages in memory between server requests, so we will make this a stateful session bean.

Example 1.11. MessageManagerBean.java

@Stateful
@Scope(SESSION)
@Name("messageManager")
public class MessageManagerBean implements Serializable, MessageManager
{
   @DataModel
   private List<Message> messageList;
   
   @DataModelSelection
   @Out(required=false)
   private Message message;
   
   @PersistenceContext(type=EXTENDED)
   private EntityManager em;
   
   @Factory("messageList")
   public void findMessages()
   {
      messageList = em.createQuery("select msg from Message msg order by msg.datetime desc")
                      .getResultList();
   }
   
   public void select()
   {          
      message.setRead(true);
   }
   
   public void delete()
   {          
      messageList.remove(message);
      em.remove(message);
      message=null;
   }
   
   @Remove
   public void destroy() {}

}

	The `@DataModel` annotation exposes an attibute of type `java.util.List` to the JSF page as an instance of `javax.faces.model.DataModel`. This allows us to use the list in a JSF `<h:dataTable>` with clickable links for each row. In this case, the `DataModel` is made available in a session context variable named `messageList`.
	The `@DataModelSelection` annotation tells Seam to inject the `List` element that corresponded to the clicked link.
	The `@Out` annotation then exposes the selected value directly to the page. So every time a row of the clickable list is selected, the `Message` is injected to the attribute of the stateful bean, and the subsequently outjected to the event context variable named `message`.
	This stateful bean has an EJB3 extended persistence context. The messages retrieved in the query remain in the managed state as long as the bean exists, so any subsequent method calls to the stateful bean can update them without needing to make any explicit call to the `EntityManager`.
	The first time we navigate to the JSP page, there will be no value in the `messageList` context variable. The `@Factory` annotation tells Seam to create an instance of `MessageManagerBean` and invoke the `findMessages()` method to initialize the value. We call `findMessages()` a factory method for `messages`.
	The `select()` action listener method marks the selected `Message` as read, and updates it in the database.
	The `delete()` action listener method removes the selected `Message` from the database.
	All stateful session bean Seam components must have a method with no parameters marked `@Remove` that Seam uses to remove the stateful bean when the Seam context ends, and clean up any server-side state.

Note that this is a session-scoped Seam component. It is associated with the user login session, and all requests from a login session share the same instance of the component. (In Seam applications, we usually use session-scoped components sparingly.)

1.3.1.3. The session bean local interface: `MessageManager.java`

All session beans have a business interface, of course.

Example 1.12. MessageManager.java

@Local

public interface MessageManager

{

   public void findMessages();

   public void select();

   public void delete();

   public void destroy();

}

From now on, we won't show local interfaces in our code examples.

Let's skip over components.xml, persistence.xml, web.xml, ejb-jar.xml, faces-config.xml and application.xml since they are much the same as the previous example, and go straight to the JSP.

1.3.1.4. The view: `messages.jsp`

The JSP page is a straightforward use of the JSF <h:dataTable> component. Again, nothing specific to Seam.

Example 1.13. messages.jsp


<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>

<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>

<html>

 <head>

  <title>Messages</title>

 </head>

 <body>

  <f:view>

   <h:form>

     <h2>Message List</h2>

     <h:outputText value="No messages to display" 

                   rendered="#{messageList.rowCount==0}"/>

     <h:dataTable var="msg" value="#{messageList}" 

                  rendered="#{messageList.rowCount>0}">

        <h:column>

           <f:facet name="header">

              <h:outputText value="Read"/>

           </f:facet>

           <h:selectBooleanCheckbox value="#{msg.read}" disabled="true"/>

        </h:column>

        <h:column>

           <f:facet name="header">

              <h:outputText value="Title"/>

           </f:facet>

<