Jesse Sweetland's Programming Blog

JSF Session Timeouts

Sat, 13 Jan 2007 19:03:10 GMT

If the application handles its own authentication, one can detect session timeouts by initializing a "User" object or token in the session immediately after authenticating and checking to see whether it is null using a filter. (There are some problems with using a filter, namely that you must exclude the login page request URI from the null user check to avoid endless dispatch loops.) In JSF this would mean storing the "User" object/token in a property of a session-scoped managed bean. (If the "User" object is itself a session-scoped managed bean, then JSF will automatically initialize it upon request, so it will never be null. One can still check the properties of a session-scoped user object for null values to detect a session timeout.)

But what if the application does not handle its own authentication? Suppose the application server is configured with a JAAS LoginModule and the web application is configured to use basic authentication? The user principal is now part of the request. It could be stored in the session, but the application is completely unaware of when authentication occurs and does not control the initial page the user sees. (The user can navigate to any URI to trigger authentication and will be served that URI if authenticated.) Worse, authentication is not tied to the session, so the session can timeout several times before the user is actually "logged out" (by closing the browser.)

So if JSF creates session-scoped managed beans on demand, how does one detect whether the bean was just created? One approach would be to assume that if certain properties in the session scoped bean are null then the bean hasn't been properly initialized and must be new. (A better way of looking at this is if a certain property is null then the session bean is in an invalid state, and the user must restart a transaction.) This might work, but it would require manipulation of properties that may not have anything to do with the application, and will most likely result in a kludgy workaround.

And supposing that a session timeout can be detected, where should it be detected? How should it be handled? Ideally the user should be redirected to a "timeout" page and be given the ability to return to a stable state. Can this be accomplished using a filter?

Using filters in JSF is problematic for several reasons. First, before processing the filter chain there is no FacesContext. On the request side, filters are invoked before FacesServlet, so there is no reasonable expectation that a FacesContext or any of its facilities will be available. Detecting timeouts on the response side is useless, because by then the application has barfed with all kinds of NullPointerExceptions due to the timeout. Finally, filters operate on ServletRequest and ServletResponse, so there are all kinds of casts and checks that have to be made before HTTP properties can be used. Filters are brittle for HTTP applications in general and for JSF applications in particular.

A JSF PhaseListener provides more granular control over the JSF lifecycle, and, more importantly, a FacesContext. The session timeout needs to be detected as early as possible, so the detection code should be implemented during the RESTORE_VIEW phase in the beforePhase method:

faces-config.xml

<faces-config> <lifecycle> <phase-listener> SessionTimeoutPhaseListener </phase-listener> </lifecycle> </faces-config>

SessionTimeoutPhaseListener.java

public class SessionTimeoutPhaseListener { public void beforePhase(PhaseEvent event) { // Session detection code goes here } public void afterPhase(PhaseEvent event) { // Do nothing } public PhaseId getPhaseId() { return PhaseId.RESTORE_VIEW; } }

Session-scope managed beans are created on demand, but JSF still provides control over whether a session is instantiated. The getSession(boolean) method of ExternalContext will return null if there is no session:

SessionTimeoutPhaseListener.java

But there is one problem with this approach. On the first request to the application, there is no session. The user shouldn't be presented with a timeout message the first time he accesses the application. Note that the only time it really matters whether a user's session has timed out is when a form is posted back to the application and there is no backing bean property to update or action method to invoke. (Generally speaking, the application will barf during the APPLY_REQUEST_VALUES or UPDATE_MODEL_VALUES phases before it even gets to INVOKE_APPLICATION or RENDER_RESPONSE.) So whether the request is a postback can be approximated by determining whether there are any request parameters:

SessionTimeoutPhaseListener.java

Finally, once a timeout has been detected, something has to happen. The ViewHandler can be used to render a timeout page and end the request:

SessionTimeoutPhaseListener.java

public class SessionTimeoutPhaseListener { public void beforePhase(PhaseEvent event) { FacesContext facesCtx = event .getFacesContext(); ExternalContext extCtx = facesCtx .getExternalContext(); HttpSession session = (HttpSession)extCtx .getSession(false); boolean newSession = (session == null) || (session.isNew()); boolean postback = !extCtx .getRequestParameterMap().isEmpty(); boolean timedout = postback && newSession; if(timedout) { Application app = facesCtx.getApplication(); ViewHandler viewHandler = app.getViewHandler(); UIViewRoot view = viewHandler.createView( facesCtx, "/sessionTimeout.xhtml"); facesCtx.setViewRoot(view); facesCtx.renderResponse(); try { viewHandler.renderView(facesCtx, view); facesCtx.responseComplete(); } catch(Throwable t) { throw new FacesException( "Session timed out", t); } } } public void afterPhase(PhaseEvent event) { // Do nothing } public PhaseId getPhaseId() { return PhaseId.RESTORE_VIEW; } }

Note that renderView and responseComplete must be invoked to prevent the JSF Lifecycle from continuing on with the RESTORE_VIEW processing, which will cause the originally requested page to be used instead, which obviates any of the work done in the PhaseListener.

TabbedPane Facelets Support

Sun, 24 Dec 2006 02:54:30 GMT

I improved Facelets support by adding bean properties to UITabbedPane and UITab instead of relying on attributes (although TabbedPaneTag and TabTag still access the properties through the attributes map using ComponentUtil). This should get rid of the "attribute XXX not found" warnings Facelets generates when it can't find bean properties and sets attributes instead.

I also added some code to delay updating the selected tab until the render response phase. Switching at the end of the APPLY_REQUEST_VALUES phase (in the decode method) can cause problems during PROCESS_UPDATES and PROCESS_VALIDATIONS, especially if Hibernate is involved.

This is probably stable enough to start tracking releases . . . here is release 1 build 1 (r1b1):

sweetfaces_r1b1.tar.gz

TabbedPane Bug Fixes

Tue, 19 Dec 2006 02:45:34 GMT

I found and fixed a couple pretty serious bugs in the processDecodes and saveDescendentState methods of UITabbedPane. These bugs resulted in the following behavior:

ValueChangeListeners, converters, and validation listeners were applied to the new tab instead of the tab that was just visible, which mean:
- Events do not fire correctly
- Request values are not applied correctly
- Hibernate LazyInitializationExceptions if your tabs are backed by lazy loading entities
EditableValueHolder value bindings were evaluated during APPLY REQUEST VALUES, which causes:
- Hibernate LazyInitializationExceptions if your tabs are backed by lazy loading entities
- Unpredictable results (when combined with the above behavior)
Value binding expressions to be stored as local values, thus preventing evaluation after INVOKE APPLICATION

These have all been resolved with some very minor changes to code. Additionally, I've added some static methods to UITabbedPane, findTabbedPaneAncestor and findTabbedPaneDescendent, that are useful for obtaining a reference to an enclosing or enclosed UITabbedPane component (since component binding is not yet available). I've also added the ability to set the selected tab index programmatically via a new setSelectedTabIndex method on UITabbedPane.

The distribution package has been updated. It can be found here:

sweetfaces.tar.gz

The next update will improve facelets support by adding true property accessors to UITabbedPane and UITab to avoid "attribute XXX not found" warnings, and by removing the "Invalid child component of UITabbedPane" messages (which happen as a result of the UIInstruction components inserted by facelets).

Hibernate Backref

Thu, 30 Nov 2006 21:00:51 GMT

Under certain circumstances Hibernate will issue the following error:

org.hibernate.PropertyValueException: not-null property references a null or transient value: foo.Bar._barsBackref at org.hibernate.engine.Nullability.checkNullability(Nullability.java:72) at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:265) at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:167) at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:114) at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.saveWithGeneratedOrRequestedId(DefaultSaveOrUpdateEventListener.java:186) at org.hibernate.event.def.DefaultSaveEventListener.saveWithGeneratedOrRequestedId(DefaultSaveEventListener.java:33) at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.entityIsTransient(DefaultSaveOrUpdateEventListener.java:175) at org.hibernate.event.def.DefaultSaveEventListener.performSaveOrUpdate(DefaultSaveEventListener.java:27) at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.onSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:70) at org.hibernate.impl.SessionImpl.fireSave(SessionImpl.java:524) at org.hibernate.impl.SessionImpl.save(SessionImpl.java:514) at org.hibernate.impl.SessionImpl.save(SessionImpl.java:510) ...

This happens when:

There two or more entities have a collection of foo.Bars; and
The collection mappings are inverse="false"; and
The collection associations all map to the same table; and
The association of at least one of those entities is not-null="true"

For example, suppose the following mappings:

Foo.hbm.xml

<!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN" "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd"> <hibernate-mapping package="foo" schema="foo"> <class name="Foo" table="foo"> <id name="id" column="foo_id" unsaved-value="null"> <generator class="native"> <param name="sequence">sq_foos</param> < </id> <version name="version"/> <set name="bars" table="foo_bar" cascade="all-delete-orphan" lazy="true"> <key column="foo_id" not-null="true"/> <many-to-many class="foo.Bar" column="bar_id"/> </class> </hibernate-mapping>

Oof.hbm.xml

<!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN" "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd"> <hibernate-mapping package="oof" schema="foo"> <class name="Oof" table="oof"> <id name="id" column="oof_id" unsaved-value="null"> <generator class="native"> <param name="sequence">sq_oofs</param> < </id> <version name="version"/> <set name="bars" table="oof_bar" cascade="all-delete-orphan" lazy="true"> <key column="oof_id" not-null="true"/> <many-to-many class="foo.Bar" column="bar_id"/> </class> </hibernate-mapping>

Here we have two classes, Foo and Oof, that hava a many-to-many association to Bar. (A common scenario would be to have Account and Order entities that both have many-to-many associations with a Contact entity.)

What happens is that somehow in Hibernate these two mappings get coalesced into a single "bars" persister. (I suspect this is because they are the same class mapped to the same table.) This persister tracks all of the properties in Bar plus backrefs (back references) for each of the entities that contain "bars". In the above example there would be two additional values, _fooBackref and _barBackref.

During a flush operation, Hibernate checks nullability of all of these values, including the backrefs. It checks all of the backrefs, regardless of what the owning entity is. If we're saving a Foo with a bunch of Bars in it, then the _oofBackref would necessarily be null and would fail the check, resulting in the stack trace above.

There are a couple of ways to work around this issue:

Remove not-null="true" from all collection associations; or
Make the collection mappings bidirectional with inverse="true"

In the case of many-to-many associations the first option isn't a problem, since many-to-many inserts must happen after the inserts on both sides of the associations, meaning the key values will never be null anyway. (I've only ever encountered this problem in many-to-many scenarios.) The second solution may work better for one-to-many associations.

TabbedPane Updates

Wed, 22 Nov 2006 01:24:43 GMT

Fixed numerous issues with the TabbedPane and added several enhancements:

Changed processDecodes to operate only on the active tab, not all tabs
Fixed bug that caused action and actionListener methods to fire on every postback
Added missing "rendered" attribute for tab in the TLD
Tabs can now be disabled (rendered but not clickable)
Different styles and classes can now be applied to individual tabs
Tabs can now be images
Reduced debug logging

Updated distribution files are here.

Fri, 10 Nov 2006 01:30:59 GMT

Added Facelets support to the tabbed pane components. If you aren't using Facelets, then you should be.

Updated binaries and source are here:

sweetfaces.tar.gz

Tabbed Pane Component

Tue, 31 Oct 2006 03:46:01 GMT

A while back I spent a little time digging around for a JSF tabbed pane component for a project I was working on. In this particular project, there were views in which there were a fixed number of tabs and also views in which I need to dynamically generate a set of tabs from a list of objects. I also needed the ability to render the tabs on top or on the right. I didn't find any components that met this criteria, so I wrote my own modeled after the UIData component in the JSF-RI.

The result is actually two components that operate in tandem similar to dataTable and column. The tabbedPan component sets up the context and visual aspects of the tabbed pane, and the tab components represent the individual tabs. There are main modes of operation: static or dynamic. In the former, the value of the tabbedPane component is empty. Nested within the tabbedPane is a tab component for each tab. Each tab is displayed only once and the number or arrangement of tabs does not change.

In the dynamic mode, the value attribute of the tabbedPane component is an EL expression that references a Collection, Iterator, Enumeration, or array, and the var attribute is the name of the variable that aliases each element in the value expression (just like a dataTable). A tab component is nested inside the tabbedPane and functions like a column in a dataTable--a new tab is rendered for each element in the value expression. (You can actually nest more than one tab component inside the tabbedPane. The result is that all of the nested tab components are rendered for each element for a total of n X m tabs, where n is the number of elements in the value expression and m is the number of nested tab components.)

The tabbedPane also allows the designer to specify an orientation, so that the tabs are rendered on the left, top, right, or bottom. There are numerous attributes for customizing the styles used to render active and inactive tabs, making the presentation fully customizable.

Finally, you can add action or actionListener methods on the tabbedPane to invoke custom code when a tab is clicked. (The tabbed pane handles its own state, but this might be a useful hook for incremental loading of data.)

Examples

<%@taglib prefix="f" uri="http://java.sun.com/jsf/core"%> <%@taglib prefix="h" uri="http://java.sun.com/jsf/html"%> <%@taglib prefix="s" uri="sweetfaces"%> <h1>Static Tabbed Pane<h1> <s:tabbedPane layout="left"> <s:tab name="World"><%include file="world.jsp"%></s:tab> <s:tab name="US"><%include file="us.jsp"%></s:tab> <s:tab name="Sports"><%include file="sports.jsp"%></s:tab> <s:tab name="Weather"><%include file="weather.jsp"%></s:tab> <s:tab name="Entertainment"><%include file="entertainment.jsp"%></s:tab> <s:tab name="Business"> <h2>This is the business section . . . <h2> <p>Foo . . . <p> </s:tab> </s:tabbedPane> <h1>Static Tabbed Pane<h1> <s:tabbedPane layout="left" value="#{news.sections}" var="section"> <s:tab name="#{section.title}" page="#{section.url}"/> </s:tabbedPane>

Download

sweetfacs.tar.gz 1.877 MB (Source and binaries)

Java 5 Generics, Polymorphism, and Hibernate

Tue, 17 Oct 2006 23:41:20 GMT

I ran into an interesting problem today while working with Hibernate. After loading an object graph and committing the session (with no modifications to the object graph) I noticed that Hibernate was issuing updates and deletes similar to the following:

update my_table set fk_column=null where id_column=? delete from my_table where id_column=?

I also began to notice sporadic occurrences of the following error:

org.hibernate.HibernateException: A collection with cascade="all-delete-orphan" was no longer referenced by the owning entity instance: my.package.Class.collectionProperty

The properties referenced in the HibernateExceptions were the same properties associated with the updates and deleted. The root cause seems to have something to do with the fact that these properties were:

Inherited from a base class
Prototyped using generics

The base class was something similar to this:

public class EntityWithReferences extends Entity { protected Set _references = new LinkedHashSet(); public Set getReferences() { return _references; } public void setReferences(Set references) { _references = references; } public void addReference(T reference) { if(reference != null) _references.add(reference); } public Set getReferences(String system) { Set sysRefs = new LinkedHashSet(); for(T reference: _references) { if(reference.getSystem().equals(system)) { sysRefs.add(reference); } } return sysRefs; } // Other common reference behavior }

And my subclasses were something like this:

public class Account extends EntityWithReferences { // Account properties and behavior }

Naturally each subclass has its own corresponding subclass of Reference, hence the generics. What I found though is that somehow Hibernate thinks that these inherited collections are not associating with the "owning entity" (the subclasses of EntityWithReferences). By getting rid of the generic base class and moving the reference behavior into the subclasses, all of the symptoms disappeared. The resulting subclasses now look something like this:

public class Account extends Entity { public Set _references = new LinkedHashSet(); public Set getReferences() { return _references; } public void setReferences(Set references) { _references = references; } public void addReference(AccountReference reference) { if(reference != null) _references.add(reference); } public Set getReferences(String system) { Set sysRefs = new LinkedHashSet(); for(AccountReference reference: _references) { if(reference.getSystem().equals(system)) { sysRefs.add(reference); } } return sysRefs; } // Other reference behavior // Account properties and behavior }

This isn't ideal, as now I have to carry all of this biolerplate code around for reference handling, but it does solve my immediate problems. Here's hoping that this will save someone else a lot of time.

"/usr/bin/ld: Undefined Symbol" on Mac OS

Sun, 13 Nov 2005 03:01:26 GMT

Just ran across a really annoying quirk in the Mac OS gcc linker. The following makefile failed with numerous "undefined symbols" even though I was linking to the correct libraries (or so I thought):

CFLAGS=-g -Wall -I${PVM_ROOT}/include/ LDFLAGS=-L${PVM_ROOT}/lib/${PVM_ARCH}/ -lpvm3 all: clean problem1_pvm MatrixTest clean: rm -f *.o rm -f problem1_pvm problem1_pvm: problem1_pvm.o Matrix.o Exception.o $(CC) $(LDFLAGS) -o $@ problem1_pvm.o Matrix.o Exception.o MatrixTest: MatrixTest.o Matrix.o Exception.o $(CC) $(LDFLAGS) -o $@ MatrixTest.o Matrix.o Exception.o problem1_pvm.o: problem1_pvm.c problem1_pvm.h $(CC) $(CFLAGS) -o $@ -c problem1_pvm.c MatrixTest.o: MatrixTest.c $(CC) $(CFLAGS) -o $@ -c MatrixTest.c Matrix.o: Matrix.c Matrix.h $(CC) $(CFLAGS) -o $@ -c Matrix.c Exception.o: Exception.c Exception.h $(CC) $(CFLAGS) -o $@ -c Exception.c

The problem was that I had $(LDFLAGS) before the object files in command line. It has something to do with the Mac OS gcc being a single-pass linker or something. Anyway, moving $(LDFLAGS) to the end of the line solved the problem:

CFLAGS=-g -Wall -I${PVM_ROOT}/include/ LDFLAGS=-L${PVM_ROOT}/lib/${PVM_ARCH}/ -lpvm3 all: clean problem1_pvm MatrixTest clean: rm -f *.o rm -f problem1_pvm problem1_pvm: problem1_pvm.o Matrix.o Exception.o $(CC) -o $@ problem1_pvm.o Matrix.o Exception.o $(LDFLAGS) MatrixTest: MatrixTest.o Matrix.o Exception.o $(CC) -o $@ MatrixTest.o Matrix.o Exception.o $(LDFLAGS) problem1_pvm.o: problem1_pvm.c problem1_pvm.h $(CC) $(CFLAGS) -o $@ -c problem1_pvm.c MatrixTest.o: MatrixTest.c $(CC) $(CFLAGS) -o $@ -c MatrixTest.c Matrix.o: Matrix.c Matrix.h $(CC) $(CFLAGS) -o $@ -c Matrix.c Exception.o: Exception.c Exception.h $(CC) $(CFLAGS) -o $@ -c Exception.c

Hibernate Transactions and Units of Work

Mon, 19 Sep 2005 21:23:10 GMT

I won't go into depth about Hibernate or the design considerations that it brings, as there is ample documentation on the Hibernate web site. One particularly useful document is Session and Transaction Scope, which elucidates on the concepts of application (user) transactions and units of work. Suffice to say, that having experimented amply with both design patterns, session-per-request and session-per-application-transaction, I strongly prefer the former, as it provides a lot more insight and control over when data is persisted. I find it is much easier and there are far fewer surprises than with long application transactions.

I would like to note that in most cases there is a very fine line between the session-per-request pattern and what the author of the above document calls a session-per-operation anti-pattern. It is common to load an object into memory in one request and save it in the next request. Two operations in two requests averages out to be one session per operation. Because sessions are lightweight and because they cache data I do not consider session-per-operation to be anti-pattern from any standpoint other than performance, which can be remedied using a second-level cache. Of course, whenever possible it is always best to group operations in a single unit of work to enhance performance, provided it is convenient and you are not violating any transaction semantics by doing so.

The most common method for implementing the session-per-request pattern is to use the ThreadLocal Session pattern, which works well in a servlet container using filters, or in a Struts action class. It does not, however, isolate all of the concerns that are typical of every transaction. For example, although the commitTransaction method of HibernateUtil will attempt a rollback if the transaction commit fails, it will not attempt a rollback if there is an error prior to the commit, such as when a business exception that occurs mid-transaction.

The ideal solution would be to isolate those aspects (transaction error handling and recovery) by wrapping the persistence operations with a boilerplate try/catch/finally block. This could be done by generating proxies for servlets, JSF backing beans, or Struts actions, but there is no support for that at this time. The Spring framework AOP facilities may be able to accomodate this approach, but I am not familiar with Spring.

The solution I came up with was to create an abstract class called UnitOfWork with an abstract method named doWork( ) and a final method named execute( ) that wraps doWork( ) with the appropriate error handling logic. In the request handler methods, anonymous inner classes extending UnitOfWork can be created inline that contain the persistence operation. Here is the code:

UnitOfWork.java

public abstract class UnitOfWork
{
    private Throwable _transactionException = null;
    private Throwable _commitException = null;
    private Throwable _rollbackException = null;
    private Throwable _closeException = null;
    
    private boolean _committed = false;
    private boolean _rolledBack = false;
    private boolean _closed = false;
    
    protected Session _session = null;
    protected Transaction _transaction = null;
    
    public Throwable getTransactionException( )
    {
        return _transactionException;
    }    
    
    public Throwable getCommitException( )
    {
        return _commitException;
    }
    
    public Throwable getRollbackException( )
    {
        return _rollbackException;
    }
    
    public Throwable getCloseException( )
    {
        return _closeException;
    }
    
    public boolean isCommitted( )
    {
        return _committed;
    }
    
    public boolean isRolledBack( )
    {
        return _rolledBack;
    }
    
    public boolean isClosed( )
    {
        return _closed;
    }
    
    public abstract Object doWork( Object[] arguments )
    throws Throwable;
    
    private final void init( )
    throws Throwable
    {
        _transactionException = null;
        _commitException = null;
        _rollbackException = null;
        _closeException = null;
    
        _committed = false;
        _rolledBack = false;
        _closed = false;
    }
    
    public final Object execute( )
    throws UnitOfWorkException
    {
        return execute( null );
    }
    
    public final Object execute( Object[] arguments )
    throws UnitOfWorkException
    {
        Object returnValue = null;
        try
        {
            _session = HibernateUtil.openSession( );
            _transaction = _session.beginTransaction( );
            init( );
            returnValue = doWork( arguments );
            try
            {
                commit( );
                _committed = true;
            }
            catch( Throwable commitException )
            {
                _commitException = commitException;
            }    
        }
        catch( Throwable transactionException )
        {
            _transactionException = transactionException;
        }
            
        if( !_committed )
        {
            try
            {
                rollback( );
                _rolledBack = true;
            }
            catch( Throwable rollbackException )
            {
                _rollbackException = rollbackException;
            }
        }

        try
        {
            close( );
            _closed = true;
        }
        catch( Throwable closeException )
        {
            _closeException = closeException;
        }
        
        _session = null;
        _transaction = null;
        
        if( !_committed )
        {
            throwException( );
        }
        else if( !_closed )
        {
            logException( );
        }
        return returnValue;
    }
    
    public void commit( )
    throws Throwable
    {
        if( _transaction != null )
        {
            _transaction.commit( );
        }
    }
    
    public void rollback( )
    throws Throwable
    {
        if( _transaction != null )
        {
            _transaction.rollback( );
        }
    }
    
    public void close( )
    throws Throwable
    {
        if( _session != null )
        {
            _session.close( );
        }
    }
    
    private void throwException( )
    throws UnitOfWorkException
    {
        UnitOfWorkException uowe = buildException( );
        if( uowe != null )
        {
            throw uowe;
        }
    }
    
    private UnitOfWorkException buildException( )
    {
        UnitOfWorkException uowe = null;
        if( _transactionException != null )
        {
            uowe = new UnitOfWorkException( this, _transactionException );
        }
        
        if( (_commitException != null) && (uowe == null) )
        {
            uowe = new UnitOfWorkException( this, _commitException );
        }
        
        if( (_rollbackException != null) && (uowe == null) )
        {
            uowe = new UnitOfWorkException( this, _rollbackException );
        }
        
        if( (_closeException != null) && (uowe == null) )
        {
            uowe = new UnitOfWorkException( this, _closeException );
        }
        
        return uowe;
    }
    
    private void logException( )
    {
        UnitOfWorkException uowe = buildException( );
        // Commons logging, J2SE logging, Log4j, or System.out.println here
    }
}

UnitOfWorkException.java

public class UnitOfWorkException
extends RuntimeException
{
    private UnitOfWork _unitOfWork = null;
    
    public void setUnitOfWork( UnitOfWork unitOfWork )
    {
        _unitOfWork = unitOfWork;
    }
    public UnitOfWork getUnitOfWork( )
    {
        return _unitOfWork;
    }
    
    public UnitOfWorkException( )
    {
    }
    
    public UnitOfWorkException( String message )
    {
        super( message );
    }
    
    public UnitOfWorkException( Throwable cause )
    {
        super( cause );
    }
    
    public UnitOfWorkException( String message, Throwable cause )
    {
        super( message, cause );
    }
    
    public UnitOfWorkException( UnitOfWork unitOfWork )
    {
        _unitOfWork = unitOfWork;
    }
    
    public UnitOfWorkException( UnitOfWork unitOfWork, String message )
    {
        super( message );
        _unitOfWork = unitOfWork;
    }
    
    public UnitOfWorkException( UnitOfWork unitOfWork, Throwable cause )
    {
        super( cause );
        _unitOfWork = unitOfWork;
    }
    
    public UnitOfWorkException( UnitOfWork unitOfWork, String message, Throwable cause )
    {
        super( message, cause );
        _unitOfWork = unitOfWork;
    }
    
    public void printStackTrace( PrintStream out )
    {
        printStackTrace( new PrintWriter( out ) );
    }
    
    public void printStackTrace( PrintWriter out )
    {
        super.printStackTrace( out );
        if( _unitOfWork != null )
        {
            if( _unitOfWork.getCommitException( ) != null )
            {
                out.print( "Upon commit: " );
                _unitOfWork.getCommitException( ).printStackTrace( out );
            }

            if( _unitOfWork.getRollbackException( ) != null )
            {
                out.print( "Upon rollback: " );
                _unitOfWork.getRollbackException( ).printStackTrace( out );
            }

            if( _unitOfWork.getCloseException( ) != null )
            {
                out.print( "Upon close: " );
                _unitOfWork.getCloseException( ).printStackTrace( out );
            }
        }
    }
}

And here is an example of how it would be used as an anonymous inner class:

Example 1

...
    final String itemName = "Example";
    Item item = (Item)new UnitOfWork( )
    {
        public Object doWork( Object[] arguments )
        throws Throwable
        {
            String name = (String)arguments[0];
            // Create a new ItemDao using the session variable prepared
            // by the UnitOfWork execute( ) method and placed in the
            // _session instance variable of the UnitOfWork class
            return new ItemDao( _session ).getByName( name );
        }
    }.execute( new Object[] { itemName } );
    System.out.println( "My item: " + item );
    ...

In this example, all of the error handling and recovery has been replaced with an anonymous inner class declaration. Arguments and return values can be passed to and from the doWork( ) method through the execute( ) method. The only possible exception that can be thrown from execute( ) is a UnitOfWorkException, which has placeholders for exceptions that can occur at all phases of the execute( ) method. When the method returns, the programmer can be assured that all cleanup has been accomplished and the best possible effort was made to gracefully recover from any errors that might have occurred. The init( ), commit( ), rollback( ), and close( ) methods can be overridden to perform additional initialization and cleanup operations as needed (file descriptors, Oracle temporary LOBs, etc.)

Note that outer class instance variables are accessible within inner classes, so we could have changed the code to be like this:

Example 2

public class MyClass
{
    private Item _item = null;
    private final String _itemName = "Example";

    ....

    public void myMethod( )
    {
        ...
        new UnitOfWork( )
        {
            public Object doWork( Object[] arguments )
            throws Throwable
            {
                _item = new ItemDao( _session ).getByName( _itemName );
                return null;
            }
        }.execute( );
        System.out.println( "My item: " + item );
        ...
    }
    ...
}

Some notes about this design pattern:

The transaction and error handling logic operates only on the session created by the execute( ) method
- The code in the doWork( ) method is free to use any available session, or create its own, but doing so circumvents the error handling logic and defeats the purpose of the UnitOfWork class
- All work should be done using the session object stored in the _session instance variable, either directly or through Data Access Objects (DAOs) that use the session specified by the caller

There is no need for a filter or other interceptor

The session and transactions are opened and closed in the execute( ) method. All initialization and cleanup is transparent to the programmer.
- Lazy associations must be fetched within a UnitOfWork doWork( ) method
- All objects are detached outside of the UnitOfWork doWork( ) method
- Changes made to detached objects will not persist unless the objects are explicitly updated or merged

A UnitOfWork anonymous class be used to implement either the session-per-operation pattern (or anti-pattern if you like) or the session-per-request pattern depending on the content of the doWork( ) method.
- The contents of the doWork( ) method can consist of one operation or a hundred, so long as they all belong to one logical database transaction.

Works well with servlets and Struts
- Servlet class can extend UnitOfWork and implement javax.servlet.Servlet. The service( ) method of the servlet can perform some initialization and simply call execute( ) when ready (no anonymous inner class required).
- Struts action classes require anonymous inner classes (or outside helper classes), as Action classes must extend Action, and there may be more than one unit of work if DispatchAction is used.
- JSF beans should use anonymous inner classes (or outside helper classes) as there will likely be more than one action method per backing bean

Java Server Faces UISelect Components

Mon, 12 Sep 2005 23:07:55 GMT

The Java Server Faces (JSF) Reference Implementation (RI) ships with pretty spartan implementations of list components. These include the select, checkbox, and radio button components created by the following tags:

selectOneListbox

selectOneMenu

selectOneRadio

selectManyCheckbox

selectManyListbox

selectManyMenu

These components are special in that they allow a user to choose one or more values from a list of pre-defined options. These options are typically represented with nested selectItem, selectItems, and selectItemGroup tags. While seemingly straightforward, these tags are very finicky and often cause failures in the Process Validations phase that prevent action methods from being called.

Component and Value Binding

The selectOne and selectMany tags can either be bound to a value on the backing bean (via the value attribute) or to a UISelect component (via the binding component). If bound to a backing bean value, the value must be a List or an array. Sets are not supported.

A nested selectItems tag can only be bound to a value; they cannot be bound to a component. The value they are bound to must be a List of SelectItem or SelectGroup objects; or an array of SelectItems or SelectGroups. Sets are not supported.

A selectItem component is not bound to a single value. Instead, the itemLabel and itemValue attributes are specified using either string literals or Expression Language (EL) expressions to refer to bean variables. Note that if selectItem tags are chosen over a selectItems tag then the value type is limited to String.

SelectItem Values

SelectItems work best with String values. However, a SelectItem value can be any type, provided:

There is a Converter for the type

The selectItems tag is used and bound to a List or Array of SelectItem or SelectItemGroup objects

I have had very little luck with either of the following scenarios:

Using nested selectItem tags with string literals and an explicit converter attribute on the enclosing selectOne or selectMany tag

Using nested selectItem tags with string literals and an explicit converter tag

Using nested selectItem tags with EL expressions refering to object values in a backing bean

Using converters registered by ID

Validation

The selectOne and selectMany tags are unique in that they have an implicit validation step that occurs in the Process Validations phase: the value specified in the request must be contained in the list (or array) of SelectItem objects that is associated with the selectOne or selectMany tag. If the supplied request value is not, then a FacesMessage is queued on the componend with the summary text "Validation Error: Value is not valid" and the Process Validations phase jumps directly to the Render Response phase, bypassing the Invoke Application Phase.

This can be very tricky, especially if you are using a custom converter, because the validation logic uses the equals( ) method of the object on each element of the List (or array) of SelectItem objects to determine whether the object is contained in the collection. If the custom converter returns a new object instance, and the object instance does not override the equals( ) method, then this validation will always fail. The default implementation of equals( ) checks only for instance equality; two different instances of the same class, while logically equal, will not be considered equal unless there is an overridden equals( ) method.

Example: Selectable Domain Objects

Suppose there is a table called LIST_ITEM with the columns ID and LABEL. Through some ORM magic the values in this table can be read into a List of ListItem objects with the properties "id" and "label". We would like to render a drop-down list of SelectItems whose values are the ListItem IDs and whose labels are the ListItem labels. To do so, we have written a ListItemConverter and have registered it to the class ListItem. The getAsObject( ) method of the converter queries queries the database for a LIST_ITEM row with an ID that is equal to the supplied value. A new ListItem is created and populated with the values from the ResultSet, and the ListItem is returned from the Converter.

In this approach, each call to getAsObject produces a new instance. Therefore it is important to override the equals( ) method of ListItem like so:

public boolean equals( Object o )
{
    if( this == o ) return true;
    if( o == null ) return false;
    if( !(o instanceof ListItem) ) return false;
    ListItem that = (ListItem)o;
    return getID( ).equals( that.getId( ) ); // getLabel( ) could be used if unique
}

This will guarantee that the ListItem created by getAsObject will appear in the collection of SelectItems.

Fail-proof Approach

I have used the following design extensively and have had very good success with it:

Ensure there is a Converter implementation for the desired type registered by class

Bind the selectOne or selectMany tag to a List or object array of the desired type

Use a nested selectItems tag bound to a bean property that returns a List of SelectItems

In the backing bean property, set the SelectItem values to be objects of the desired type. Do not convert to a String. Set the label to be whatever String value is desired.

In the Class specification for the desired type, override the equals method to determine equality based on a unique key, preferrably a secondary key (business key).

Complete Example

ListItem.java

public class ListItem
{
    private long _id = -1;
    private String _label = null;

    public void setId( long id )
    {
        _id = id;
    }
    public long getId( )
    {
        return _id;
    }

    public void setLabel( String label )
    {
        _label = label;
    }
    public String getLabel( )
    {
        return _label;
    }

    public boolean equals( Object o )
    {
        if( this == o ) return true;
        if( o == null ) return false;
        if( !(o instanceof ListItem) ) return false;
        ListItem that = (ListItem) that;
        return getId( ) == that.getId( );
    }
}

ListItemConverter.java

public class ListItemConverter
implements Converter
{
    public Object getAsObject( FacesContext context, UIComponent component, String string )
    throws ConverterException
    {
        return new ListItemDao( ).loadById( Integer.parseInt( string ) );
    }

    public String getAsString( FacesContext context, UIComponent component, Object object )
    {
        return String.valueOf( ((ListItem)object).getId( ) );
    } 
}

BackingBean.java

public class BackingBean
{
    private ListItem[] _selectedListItems = null;

    public List getListItemSelectItems( )
    {
        List listItemSelectItems = new List( );
        List listItems = new ListItemDao( ).loadAll( );
        for( Iterator liIter = listItems.iterator( ); liIter.hasNext( ); )
        {
            ListItem li = (ListItem)liIter.next( );
            listItemSelectItems.add( new SelectItem( li, li.getLabeL( ) );
        } 
        return listItemSelectItems;
    }

    public void setSelectedListItems( ListItem[] selectedListItems )
    {
        _selectedListItems = selectedListItems;
    }
    public ListItem[] getSelectedListItems( )
    {
        return _selectedListItems;
    }
}

faces-config.xml

...
<converter>
    <converter-for-class>ListItem</converter-for-class>
    <converter-class>ListItemConverter</converter-class>
</converter>
...
<managed-bean>
    <managed-bean-name>backingBean</managed-bean-name>
    <managed-bean-class>BackingBean</managed-bean-class>
</managed-bean>
...

example.jsf

...
<h:selectOneMany value="#{backingBean.selectedListItems}">
    <f:selectItems value="#{backingBean.listItemSelectItems}"/>
</h:selectOneMany>
...

Hierarchical Navigation in JSF

Sat, 03 Sep 2005 04:43:14 GMT

(Note: I typed this up in TextEdit. The code provided is for illustration purposes and was not tested. If there are any errors, please post corrections in the article comments.)

One of the biggest problems I encountered when learning Java Server Faces (JSF) was figuring out the best way to navigate from a list of items to a view or edit screen for a particular item in the list. By "best" I mean one that is in the spirit of the framework and is not difficult to implement or unreadable. The scenario I will discuss happens pretty frequently in the applications I work with, but it is not specifically addressed in Core Java Server Faces or any of the tutorials I have encountered on the web.

The setup is this: one page (items.jsp) contains a table with one row per item. Each row has a button or a link that takes the user to the next page, editItem.jsp, which contains a form allowing the user to view and change the properties for a particular item. When the editItem.jsp form is submitted, the user is taken back to items.jsp and the changes are visible. This model can of course be more complex, such as in the case where there is a whole heirarchy of objects (Category -> SubCategory -> Item -> Feature).

The old way of doing things was to create a servlet (EditItem.java) that:

looks for a request parameter ("itemId")

loads that item from a persistent store

stores the item in the request or session context

forwards to editItem.jsp

Each row of the table in items.jsp would have a link explicitly specifying the GET method parameter "itemId" so that the item ID passed to EditItem.java varies depending on which link (row) is clicked. A POST method solution can be achieved by using submit inputs in lieu of links and using a Javascript onclick event to populate a hidden form input named "itemId" before the form is submitted (this is, in fact, how Struts implements some of the controls).

JSF can coexist with servlets, but in using the approach described above I find that most of the application logic ends up taking place in servlets, using JSF only for component binding or backing beans. It is possible to access the request map through the external context but that is kind of dodgy. What we would like to do is call a backing bean method and have that method infer which row was clicked on using only JSF components and events. Other than the request parameter trick, there are a couple good ways to do this.

Component Attributes

One approach would be to add an attribute to the <h:commandButton> or <h:commandLink> component and then bind the component to an action listener method on the backing bean. Note that an action listener method differs from a normal action method in that it is passed an ActionEvent parameter that provides a pointer to the UICommand component that invoked the method. The attribute, in this case the item ID, can be read from the UICommand component's attribute map and used to load the appropriate Item. This item is then stored in another backing bean property, currentItem, so it can be referenced by editItem.jsp.

This approach has a drawback: your backing bean must be session-scoped. This means that cleanup may be necessary to prevent a previously selected Item from bleeding over onto another form. For example, suppose an Item was selected and then edited. Afterward, the user chooses to create a new item. If the addItem.jsp page also uses the currentItem property of the backing bean, then it is possible that the addItem.jsp page will show the data for the Item that was just edited. To prevent this, either create a currentItem property for each page; use separate backing beans; or set currentItem to null whenever changes are committed to the persistent store or abandoned.

Code

items.jsp

...
<f:form>
   <h:dataTable value="#{itemBean.items}" var="i">
      <h:column>
         <f:facet name="header"><f:verbatim>Name</f:verbatim></f:facet>
         <h:outputText value="#{i.name}"/>
      </h:column>
      <h:column>
         <f:facet name="header"><f:verbatim>Action</f:verbatim></f:facet>
         <h:commandButton value="Edit" actionListener="#{itemsBean.editItem}">
             <f:attribute name="itemId" value="#{i.id}"/>
         </h:commandButton>
      </h:column>
   </h:dataTable>
</f:form>
...

ItemBean.java

public class ItemBean
{
    private Item _currentItem = null;
    public void setCurrentItem( Item currentItem )
    {
        _currentItem = currentItem;
    }
    public Item getCurrentItem( )
    {
        return _currentItem;
    }

    public List getItems( )
    {
        return new ItemDao( ).loadAll( );
    }

    public String editItem( ActionEvent event )
    {
        UICommand command = (UICommand)event.getComponent( );
        String itemId = (String)command.getAttributes( ).get( "itemId" );
        Item itemToEdit = new ItemDao( ).loadById( itemId );
        setCurrentItem( itemToEdit );
        return "success";
    }

    public String saveCurrentItem( )
    {
        new ItemDao( ).save( getCurrentItem( ) );
        setCurrentItem( null );
        return "success";
    }
}
...

editItem.jsp

...
<h:inputLabel for="name"><f:verbatim>Name</f:verbatim></h:inputLabel>
<h:inputText id="name" value="#{itemBean.currentItem.name}"/>
<h:commandButton value="Save" action="#{itemBean.saveCurrentItem"/>
...

Decorators

This is a very involved approach. I prefer it because it makes use of the Inversion of Control (IOC) and offers a very clean delineation between the model (POJO) and view/controller (JSF). Such a loose coupling of frameworks allows interchangeability of frameworks (JSF, Spring, Hibernate) and offers a clean separation of concerns.

A <h:dataTable> iterates over a list and assigns each element in the list to a temporary variable (i) that can be used to extract property values specific to each item in a list. We used that functionality in the previous approach to extract the ID from each item and assign it to an attribute on an action listener method. That method used the attribute value to load the appropriate Item and initialized the currentItem property of ItemBean for use by editItem.jsp. In the previous example, all of the <h:commandButton> components were bound to the same method of the session-scoped bean ItemBean. Instead of binding every <h:commandButton> to the same method, couldn't they be bound to a method of the temporary variable (#{i.editItem})?

This has very interesting implications. If the <commandButton> is bound directly to a method on the Item, then do we still need to pass the itemId? No, because the method only has access to one Item: the Item that is the object instance the method was invoked on.

But does this really solve any problems? Suppose that the Item object has a method called editThisItem and that every <h:commandButton> is bound to the editThisItem method of a particular Item instance. The method knows which Item to operate on, and what's more, it doesn't need to load it from the persistent store. All that is left is to navigate to editItem.jsp... so why even bother invoking the method in the first place?

The problem is that when editItem.jsp loads, it will have nothing to reference. In the previous approach, a property called currentItem was initialized and referenced by editItem.jsp. Something similar must be done with this approach--the editThisItem method must store a reference to its Item instance in a managed bean so that it can be used by editItem.jsp. Here is where it gets involved.

Three managed beans are needed:

SessionBean - a session-scoped bean that holds a pointer to the current item

ItemsBean - a request-scoped bean that contains a list of ItemBeans

ItemBean - a decorator for a Item instance that exposes action methods. Also a request-scoped bean used by editItem.jsp.

Both ItemsBean and ItemBean contain a property named sessionBean that stores a reference to the SessionBean instance. ItemBean also has a propert named item that points to the Item instance it wraps. Both of these are managed properties that are initialized by the JSF container when the beans are iniitalized.

The <h:dataTable> in items.jsp iterates over the itemBeans collection of the ItemsBean bean. The temporary variable stores an ItemBean reference that can be used to refer to the Item that is being wrapped (item) or the action method (editThisItem). The editThisItem method of ItemBean will initialize the currentItem property of sessionBean. The editItem.jsp page will use an ItemBean backing bean whose item property will be initialized with the value of currentItem from the sessionBean by the JSF container.

The sequence of events is this:

SessionBean instance is created as sessionBean

ItemsBean instance is created as itemsBean. itemsBean.sessionBean is initalized with sessionBean.

itemBeans property is initialized as a List of unmanaged ItemBean elements

items.java initializes <h:dataTable>

<h:commandButton> is clicked

editThisItem method is invoked. sessionBean.item is initalized with the Item instance wrapped by the ItemBean decorator.

ItemBean instance is created as itemBean. itemBean.sessionBean is initialized with sessionBean. itemBean.item is initialized with sessionBean.item

edit.jsp extracts values from and applies values to itemBean.item

Code

SessionBean.java

public class SessionBean
{
    private Item _currentItem = null;
    public void setCurrentItem( Item currentItem )
    {
        _currentItem = currentItem;
    }
    public Item getCurrentItem( )
    {
        return _currentItem;
    }
}

ItemsBean.java

public class ItemsBean
{
    private SessionBean _sessionBean = null;
    public void setSessionBean( SessionBean sessionBean )
    {
        _sessionBean = sessionBean;
    }

    public List getItemBeans( )
    {
        List items = new ItemDao( ).loadAll( );
        List itemBeans = new ArrayList( );
        for( Iterator itemIter = items.iterator( ); itemIter.hasNext( ); )
        {
            itemBeans.add( new ItemBean( _sessionBean, (Item)itemIter.next( ) ) );
        }
        return itemBeans;
    }
}

ItemBean.java

public class ItemBean
{
    private SessionBean _sessionBean = null;
    public void setSessionBean( SessionBean sessionBean )
    {
        _sessionBean = sessionBean;
    }

    private Item _item = null;
    public void setItem( Item item )
    {
        _item = item;
    }
    public Item getItem( )
    {
        return _item;
    }

    public ItemBean( ) { }
    public ItemBean( SessionBean sessionBean, Item item )
    {
        _sessionBean = sessionBean;
        _item = item;
    }

    public String editThisItem( )
    {
        _sessionBean.setCurrentItem( _item );
        return "success";
    }

    public String removeThisItem( )
    {
        new ItemDao( ).delete( _item );
        return "success";
    }

    public String saveThisItem( )
    {
        new ItemDao( ).save( _item );
        return "success";
    }
}

faces-config.xml

...
<managed-bean>
    <managed-bean-name>sessionBean</managed-bean-name>
    <managed-bean-class>SessionBean<managed-bean-class>
    <managed-bean-scope>session<managed-bean-scope>
<managed-bean>
<managed-bean>
    <managed-bean-name>itemsBean</managed-bean-name>
    <managed-bean-class>ItemsBean<managed-bean-class>
    <managed-bean-scope>request<managed-bean-scope>
    <managed-property>
        <property-name>sessionBean<property-name>
        <property-class>SessionBean<property-class>
        <property-value>#{sessionBean}<property-value>
    <managed-property>
<managed-bean>
<managed-bean>
    <managed-bean-name>itemBean</managed-bean-name>
    <managed-bean-class>ItemBean<managed-bean-class>
    <managed-bean-scope>request<managed-bean-scope>
    <managed-property>
        <property-name>sessionBean<property-name>
        <property-class>SessionBean<property-class>
        <property-value>#{sessionBean}<property-value>
    <managed-property>
   <managed-property>
        <property-name>item<property-name>
        <property-class>Item<property-class>
        <property-value>#{sessionBean.item}<property-value>
    <managed-property>
<managed-bean>
...

items.jsp

...
<f:form>
   <h:dataTable value="#{itemsBean.itemBeans}" var="ib">
      <h:column>
         <f:facet name="header"><f:verbatim>Name</f:verbatim></f:facet>
         <h:outputText value="#{ib.item.name}"/>
      </h:column>
      <h:column>
         <f:facet name="header"><f:verbatim>Action</f:verbatim></f:facet>
         <h:commandButton value="Edit" actionListener="#{ib.editThisItem}"/>
      </h:column>
   </h:dataTable>
</f:form>
...

editItem.jsp

...
<h:inputLabel for="name"><f:verbatim>Name</f:verbatim></h:inputLabel>
<h:inputText id="name" value="#{itemBean.item.name}"/>
<h:commandButton value="Save" action="#{itemBean.item.saveThisItem"/>
...