J-Development

Fetching arbitrary object graphs in JPA 2

development — Wed, 25 Apr 2012 15:12:05 +0000

In Java EE, JPA (Java Persistence API) is used to store and retrieve graphs of objects. This works by specifying relations between objects via annotations (or optionally XML). Hand over the root of an object graph to the entity manager and it will persist it. Ask the entity manager for an object with a given Id and you’ll get the graph back.

This is all fine and well, but how in this model do we control which branches of the graph are retrieved and to which depth branches should be followed?

The primary mechanism to control this with is the eager/lazy mechanism. Mark a relation as eager and JPA will fetch it upfront, mark it as lazy and it will dynamically fetch it when the relation is traversed. In practice, both approaches have their cons and pros. Mark everything eager and you’ll risk pulling in the entire DB for every little bit of data that you need. Mark everything lazy, and you’ll not only have to keep the persistence context around (which by itself can be troublesome), but you also risk running into the 1 + N query problem (1 base query is fired, and then an unknown amount of N queries when iterating over its relations). If fetching 1000 items in one query took approximately as long as fetching 1 item per query and firing 1000 queries, then this wouldn’t be a problem. Unfortunately, for a relational database this is not the case, not even when using heaps of memory and tons of fast SSDs in RAID.

There are various ways to overcome this. For instance there are proprietary mechanisms for setting the batch size, so not 1000 queries are fired but 10. We could also assume that all entities relating to those 1000 items are all in the (JPA) cache. Then 1000 fetches of 1 entity are indeed about as costly as 1 fetch of 1000 entities, but this is a dangerous assumption. Assume wrong and you might bring down your DB.

The fundamental problem however is that eager/lazy are static properties of the entity model. In practice, the part of the graph that you want often depends on the use case. For a master overview of all Users in a system, you’d probably want a rather shallow graph, but for the detail view of a particular User you most likely need a somewhat deeper one.

Again, there are various solutions for this. One is to write individual JPQL queries for each use case. This certainly works, but the number of queries can grow rapidly out of hand this way (allUsersWithAddress, allUsersWithAddressAndFriends, allUsersWithAddressAndFriendsWithAddress , …). Another solution that addresses exactly this problem are the fetch profiles that were introduced in Hibernate 3.5. As can be seen in the official documentation, this solution is not particularly JPA friendly. You need access to the native Hibernate session, which is possible, but not pretty. One way or the other, fetch profiles are Hibernate specific.

In this posting I would like to present an alternative solution. It feels a little like fetch profiles, but the graph to be fetched can be specified dynamically and it uses the JPA API only. It works by using the criteria API to programmatically add one or more JOIN FETCH clauses to a query. Unfortunately JPA does not yet have the capabilities to turn a JPQL query into a Criteria query, so either the query must already be a Criteria or it should be a simple find. The following code demonstrates the latter case:

@Stateless
public class SomeDAO {
 
    @PersistenceContext
    private EntityManager entityManager;
 
    public T findWithDepth(Class<T> type, Object id, String... fetchRelations) {
        CriteriaBuilder criteriaBuilder = entityManager.getCriteriaBuilder();
        CriteriaQuery<T> criteriaQuery = criteriaBuilder.createQuery(type);
        Root<T> root = criteriaQuery.from(type);
 
        for (String relation : fetchRelations) {
            FetchParent<T, T> fetch = root;
            for (String pathSegment : relation.split(quote("."))) {
                fetch = fetch.fetch(pathSegment, JoinType.LEFT);
            }
        }
 
        criteriaQuery.where(criteriaBuilder.equal(root.get("id"), id));
 
        return getSingleOrNoneResult(entityManager.createQuery(criteriaQuery));
    }
 
    private <T> T getSingleOrNoneResult(TypedQuery<T> query) {        
        query.setMaxResults(1);
        List<T> result = query.getResultList();
        if (result.isEmpty()) {
            return null;
        }
 
        return result.get(0);
    }
}

The findWithDepth method can now be called with one or more path expressions, where each path is just a chain of properties separated by a dot (like in expression language). E.g.:

User user = someDao.findWithDepth(
    User.class, 15, "addresses", "friends.addresses"
);

The above line would fetch the user with “id” 15, and pre-fetches the addresses associated with that user, as well as the friends and their addresses. (Note that the @Id field is hardcoded to be called “id” here. A more fancy implementation could query the object for it)

This solution, though handy, is however not perfect. While all JPA vendors support fetching multiple relations of one level deep (addresses and friends in the example above), not all of them support fetching chained relations (friends.addresses in the example above). Specifically for Hibernate care should be taken to avoid fetching so-called “multiple bags” (sets and @OrderColumn are a typical solution). Of course it’s always wise to avoid creating a huge Cartesian product, which is unfortunately one low-level effect of the underlying relational DB you have to be aware of, even when purely dealing with object graphs.

Despite the problems I outlined with this approach above, I hope it’s still useful to someone. Thanks go to my co-workers Jan Beernink and Hongqin Chen for coming up with the original idea respectively refining it.

Arjan Tijms

Hibernate’s “Pure native scalar queries are not yet supported”

arjan tijms — Sun, 22 Apr 2012 20:53:12 +0000

In JPA one can define JPQL queries as well as native queries. Each of those can return either an Entity or one or more scalar values. Queries can be created on demand at run-time from a String, or at start-up time from an annotation (or corresponding XML variant see Where to put named queries in JPA?).

Of all those combinations, curiously Hibernate has never supported named native queries returning a scalar result, including insert, update and delete queries which all don’t return a result set, but merely the number of rows affected.

It’s a curious case, since Hibernate does support scalar returns in non-native named queries (thus a scalar return and named queries is not the problem), and it does support scalar returns in dynamically created native queries (thus scalar returns in native queries are not the problem either).

An example of this specific combination:

 name="SomeName">
    >
        INSERT INTO
            foo
        SELECT
            *
        FROM
            bar
    >
>

If you do try to startup with such a query, Hibernate will throw an exception with the notorious message:

Pure native scalar queries are not yet supported

Extra peculiar is that this has been reported as a bug nearly 6 years(!) ago (see HHH-4412). In that timespan the advances in IT have been huge, but apparently not big enough to be able to fix this particular bug. “Not yet” certainly is a relative term in Hibernate’s world.

A quick look at Hibernate’s source-code reveals that the problem is within org.hibernate.cfg.annotations.QueryBinder, more specifically the bindNativeQuery method. It has the following outline:

public static void bindNativeQuery(org.hibernate.annotations.NamedNativeQuery queryAnn, Mappings mappings){
    if (BinderHelper.isEmptyAnnotationValue(queryAnn.name())) {
        throw new AnnotationException("A named query must have a name when used in class or package level");
    }
    NamedSQLQueryDefinition query;
    String resultSetMapping = queryAnn.resultSetMapping();
    if (!BinderHelper.isEmptyAnnotationValue(resultSetMapping)) {
        query = new NamedSQLQueryDefinition (
            // ...
        );
    }
    else if (!void.class.equals(queryAnn.resultClass())) {        
        // FIXME should be done in a second pass due to entity name?
        final NativeSQLQueryRootReturn entityQueryReturn =
            new NativeSQLQueryRootReturn (
                // ...
            );
    }
    else {
        throw new NotYetImplementedException( "Pure native scalar queries are not yet supported" );
    }
}

Apparently, the NamedNativeQuery annotation (or corresponding XML version), should either have a non-empty resultset mapping, or a result class that’s something other than void.

So, isn’t a workaround for this problem perhaps to just provide a resultset mapping, even though we’re not doing a select query? To test this, I tried the following:

 name="SomeName" result-set-mapping="dummy">
    >
        INSERT INTO
            foo
        SELECT
            *
        FROM
            bar
    >
>
 
 name="dummy">
     name="bla" />
>

And lo and behold, this actually works. Hibernate starts up and adds the query to its named query repository, and when subsequently executing the query there is no exception and the insert happens correctly.

Looking at the Hibernate code again it looks like this shouldn’t be that impossible to fix. It’s almost as if the original programmer just went out for lunch while working on that code fragment, temporarily put the exception there, and then after lunch completely forgot about it.

Until this has been fixed in Hibernate itself, the result-set-mapping workaround might be useful.

Arjan Tijms

What’s new in JSF 2.2?

arjan tijms — Tue, 10 Apr 2012 10:00:27 +0000

JSF 2.2 is currently in an intermediate stage of development, and originally had an anticipated release of the final draft of the spec in Q4 2011 (see Jsf 2 2-bof, slide 3 and JSR 344: JavaServer Faces 2.2). This date slipped, but we might still see the actual release somewhere in the first half of 2012.

So what’s going to be in 2.2? The JSR gives an overview of ideas, but explicitly makes the reservation that not all of those will be in the final spec. So, another source worth looking at is the actual trunk of the reference implementation and its associated implementation JIRA as well as that of the public specification JIRA.

In this post I’ll try to highlight some items from that activity that I found interesting. Note that all of this is preliminary and just reflects the activity in the trunk, not what is absolutely promised to be in the final JSF 2.2 specification. Of course, if there’s a lot of activity and commits for some item, there’s a rather high chance that it will indeed end up in the spec.

Download

The milestone 1 release that contains a lot of functionality implemented before ~March 2012 can be downloaded here.

New features

GET Support
- View Actions
Navigation
- Faces Flow
AJAX
- Queue control for AJAX requests
- AJAX file upload component
Injection / Annotations
Security / Type-safety
- Cross Site Request Forgery protection
- More thorough type checking for composite component attributes
Java API
Lifecycle
Components
- Component modification management
XML configuration
- Case insensitivity for state saving method
Standards compliance
- Unique ids and fixed name attribute for view state field
- Allowing id attribute on all elements for HTML5 content

GET Support

View Actions (spec issue 758) (mentioned in JSR)

JSF 2.0 made GET requests a first class citizen in JSF and brought it almost on par with the existing POST support. Just as after a post-back, request values from a GET request can be bound to a model and converters and validators can be applied to that binding.

However, JSF 2.0 didn’t specify an associated action method. A preRenderView event listener can be used instead and that actually does work for a lot of use-cases, but it’s not at the same level as normal action methods that are invoked after a POST request. Users have to manually interact with the NavigationHandler and since the listener is invoked before every rendering, users have to programmatically check if the request was a GET request or a post-back.

View actions are going to allow the same kind of action methods that are used for post-backs to be useable via a new metadata element called . The Seam 3 component with the same name was an important inspiration for this.

An additional advantage of a view action is that it can be processed before the entire component tree is being build. Only the meta data needs to be present, which is normally build separately from the rest of the tree.

The feature is discussed in more detail together with sample code at: New JavaServer Faces 2.2 Feature: The viewAction Component

A very simple example:

1
2
3

>    
     action="#{someBean.someAction}" />
>

Commits for this feature have been done between 16/jun/11 and 18/aug/11.

Navigation

Faces Flow (spec issue 730) (mentioned in JSR)

In web applications, and in applications in general actually, there is often the concept of a “flow” that takes the user through a series of screens. Such flows includes wizards, multi-screen subscriptions, bookings, etc.

Common for such flows is that they are not a random selection of pages linked to each other, but there is clear starting point and a goal where the user comes closer to after each successive step in the flow.

Implementing such flows has in the past been done with ad-hoc techniques, like simply linking full pages to each other and using the session scope to pass information between pages. The problem here is that this makes the result difficult to re-use and not safe when the user opens the same flow in more than one window.

For the last use case CDI already presented a solution via the conversation scope (@ConversationScoped), but this is just a part of the equation and by itself doesn’t enable truly reusable flows. Inspired by Spring Web Flow and ADF Task Flows , JSF 2.2 will directly add support for this concept, most likely using the name Faces Flow.

Faces Flow is a rather big new feature, which brings with it quite an amount of new concepts and terminology in JSF. This is explained in much more detail in the official proposal.

Part of this feature will be a new annotation, @FlowScoped, which in the initial commit has the following JavaDoc:

Classes with this annotation attached to them will be considered to be in the scope of the named flow. The implementation must provide an implementation of javax.enterprise.inject.spi.Extension that implements the semantics such that beans with this annotation are created when the user enters into the named flow, and de-allocated when the user exits the named flow.

(A remarkable detail is that JSF 2.2 thus seems to introduce a dependency on CDI here, which might be indicative of JSF moving closer to CDI for other aspects as well)

A flow scope bean will look something like this:

@Named
@FlowScoped(name="someFlowName")
public class SomBean {
    // ...
}

A new element has been introduced for faces-config.xml: faces-flow-definition. At the moment it’s not yet clear how this will be used, but the current skeleton form looks like this:

 version="2.2" 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_2_2.xsd">
 
    >
 
    >
 
>

Holding up the design philosophy that as many things as possible should not require configuration in faces-config.xml, it will also be possible to put the flow definition directly into the artifacts that make up a flow. For instance, in a view the metadata element will be leveraged:

 xmlns="http://www.w3.org/1999/xhtml" xmlns:h="http://java.sun.com/jsf/html">
    xmlns:f="http://java.sun.com/jsf/core"
    xmlns:j="http://java.sun.com/jsf/flow">
    >
         id="flow"/>
    >
>

Notice the addition of a new taglib URI in core JSF: http://java.sun.com/jsf/flow. This new taglib has the following description:

Specify how a flow is declared in VDL pages. This schema is functionally equivalent to the same content in a faces-config.xml file.

As of now, the following tags have been placed in that lib:

faces-flow-definition
default-node – (Gets name of this page without any extension)
view
vdl-document – (Gets name of this page with the extension)

A few new methods have been added to the Java API, for instance javax.faces.application.Application has a new method FlowHandler getFlowHandler(). A FlowHandler can be used to obtain the current Flow or transition to a new point in the flow. A Flow can among others be asked for the Id relative to the current window. This currently consists of the Window Id and the Flow Id separated by an underscore.

At the time of writing, the implementation is only in a very early stadium and various things have not been implemented yet.

Commits for this feature have been done between 29/mar/12 and 10/apr/12.

AJAX

Queue control for AJAX requests (spec issue 1050)

The standard AJAX support in JSF causes AJAX requests to be queued client-side to make sure a page has only 1 such request in transit at the same time.

This is normally beneficial, as it prevents the server from being overloaded and responses arriving out of order. Typical features here are specifying the maximum size of the queue or the amount of time a request is allowed to sit waiting in the queue.

However, JSF lacked those features. Werner Punz wrote about this recently: Apache MyFaces jsf.js queue control.

JSF will add support for controlling the queue by means of a delay attribute on the tag. This attribute takes a value in milliseconds and signals that if multiple requests arrive within this delay period, only the most recent one is sent to the server. The default is 300 milliseconds, but the special value of none can be specified to disable this mechanism.

Commits for this feature have been done on 10/jun/11 and the associated issue has been marked as resolved.

AJAX file upload component (spec issue 802) (mentioned in JSR)

Having a (AJAX) file upload component in JSF goes back a long time. There is much existing discussion on this issue, and many component libraries have in the mean time implemented something themselves.

An AJAX variant is even more difficult, not in the least since it’s not directly supported in HTML. There’s an iframe based trick available, but this by itself does not work directly with JSF. To support this, changes are required to the mechanism that triggers a JSF request/response cycle.

A prerequisite to an AJAX file upload mechanism is having a standard file upload in JSF. For this a separate issue was created: Non-Ajax File Upload. Interesting here is that this implementation is based on Servlet 3.0 multipart support, like e.g. this implementation by my co-worker Bauke. This means among other that the venerable FacesServlet is now annotated with the @MultipartConfig annotation and that JSF now requires Servlet 3.0.

The standard file upload component can be used on a view as follows:

 prependId="false" enctype="multipart/form-data">
 
    
     id="fileUpload" value="#{someBean.file}" />
 
     value="Upload" />
>

Commits for the sub-issue have been done on 15/dec/11.

Injection / Annotations

Injection in all JSF artifacts (spec issue 763) (mentioned in JSR)

In JSF 2.1, relatively few JSF artifacts are injection targets for EJB (@EJB, @Resource), CDI (@Inject) or JSF’s native injection mechanism. Basically only managed beans (backing beans) are injection targets.

This poses a problem for e.g. converters and validators, which not rarely need an EJB service to do their work. For instance, an incoming user ID from a GET request might needs to be converted to a User instance via the Stateless EJB UserService. There are some workarounds for this as outlined in this excellent guide from my co-worker Bauke, but they ain’t pretty.

In JSF 2.2 injection will be possible in converters, validators, components, behaviors and much more artifacts.

Commits for this feature have been done between 27/aug/11 and 31/oct/11 and the associated issue had been marked as resolved, but on 11/jan/12 an additional commit was done that changed how the InjectionProvider is internally obtained by the FactoryFinder.

Facelets Component Tag can be declared via annotation (spec issue 594)(mentioned in JSR)

Before JSF 2.0, creating (java based) custom components was a lot of work. The amount of required work was largely reduced in JSF 2.0, mainly because Facelets does not require an explicit tag handler and because a component can be registered via its annotation.

However, one tedious requirement remained. In order to make a component useable in Facelets, a tag name for it had to be declared in a *-taglib.xml file.

In JSF 2.2 this requirement has been lifted and the tag declaration can be done via the component’s annotation. For this the @FacesComponent annotation introduces 3 new attributes:

createTag – If set to true the component will be directly useable via a tag on a Facelet.
tagName – Optional explicit name for the tag. If omitted, the class’ simple name with the first character in lowercase will be used.
namespace – Optional explicit namespace for the tag. If omitted the namespace ‘http://java.sun.com/jsf/component’ will be used.

For instance:

@FacesComponent(value="components.CustomComponent", createTag=true)
public class CustomComponent extends UIComponentBase {
 
    @Override
    public String getFamily() {        
        return "my.custom.component";
    }
 
    @Override
    public void encodeBegin(FacesContext context) throws IOException {
 
        String value = (String) getAttributes().get("value");
 
        if (value != null) {        
            ResponseWriter writer = context.getResponseWriter();
            writer.write(value.toUpperCase());
        }
    }
}

Without the need to configure or declare anything else, this component can now be used on a JSF 2.2 Facelet as follows:

page.xhtml

 xmlns="http://www.w3.org/1999/xhtml"
    xmlns:h="http://java.sun.com/jsf/html"
    xmlns:test="http://java.sun.com/jsf/component"
>
    >   		
         value="test"/>        
    >
>

Commits for this feature have been done between 13/feb/12 and 15/feb/12 and the associated issue has been marked as resolved.

Facelets ResourceResolver can be declared via annotation (spec issue 1038)

In Facelets it has always been possible to let users provide a hook to influence the way that Facelets loads template files. This is done via a ResourceResolver that users can register in web.xml via the environment parameter javax.faces.FACELETS_RESOURCE_RESOLVER.

With such a resolver, users can let Facelets load templates from the classpath or from any location that is expressible via a URL.

The web.xml mechanism however pre-dates the time that Facelets was officially part of JSF itself and it of course requires the presence of such a web.xml file. Since Facelets is now officially part of JSF and there is a strong trend going to make XML optional in favor of annotations, the Facelets resource resolver has now gotten an official annotation in the JSF spec:

@FaceletsResourceResolver.

The presence of that annotation on a class automatically registers it as a Facelets resource resolver. If a resolver is specified in both XML and via an annotation, the XML overrides the annotation as per the usual Java EE conventions. If multiple annotated classes are found, the first one encountered is used and a warning is logged.

Commits for this feature have been done between 06/oct/11 and 12/oct/11 and the associated issue has been marked as resolved.

Component and validator annotations default to simple class name (spec issue 703)

With Java EE 5 a trend was started to introduce convention over configuration into the platform, a trend which continued strongly in Java EE 6.

For annotations that cause a class to be registered under some name this typically means the simple class name (class name without the package) with the first letter de-capitalized is taken as the default for this name. For instance, in JSF 2 with the following class definition the managed bean will be available to EL using the name foo

@ManagedBean
public class Foo {
    // ...
}

If needed the name can be specified explicitly:

@ManagedBean(name="myfoo")
public class Foo {
    // ...
}

For components and validators this convention wasn’t used, and the name always had to be specified fully, e.g. for a component:

@FacesComponent("bar")
public class Bar extends UIComponentBase {
    // ...
}

Notice the inconsistency between “name=” for the managed bean and not having to use an attribute name for the component.

In JSF 2.2 the name can now be omitted for components, converters and validators as well, so the code shown above can become:

@FacesComponent
public class Bar extends UIComponentBase {
    // ...
}

This makes the overall platform a bit more consistent and is especially useful for simple implementations in application space. Most likely component libraries will still provide a (long) explicit name to prevent name clashes.

Commits for this feature have been done on 07/mar/12 and the associated issue has been marked as resolved.

Security / Type-safety

Cross Site Request Forgery protection (spec issue 869) (mentioned in JSR)

Cross Site Request Forgery is an attack that lets users unknowingly do a request to a site where they are supposed to be logged-in, that has some side-effect that is most likely in some way beneficial to the attacker. GET based requests are most obvious here, but POST requests are just as vulnerable.

JSF seems to have some implicit protection against this when state is saved on the server, since a post-back must contain a valid javax.faces.ViewState hidden parameter. Contrary to earlier versions, this value seems sufficiently random in modern JSF implementations.

Nevertheless, JSF 2.2 will contain additional/even stricter protection against this. Among others client state encryption is now on by default and there’s a token parameter for protection of non-postback views.

Commits for this feature have been done between 13/sep/11 and 21/sep/11.

More thorough type checking for composite component attributes (spec issue 745)

In JSF 2.1, it’s not always easy to defer the exact type of a value expression bound to an attribute of a composite component, if said expression resolves to null. Finding the right type just by asking ElResolver is complicated by the fact that ELResolver#getType is supposed to return the most general type that is accepted by the corresponding ELResolver#setValue. It’s also not always equal to getValue().getClass() as explained by the javadoc.

In JSF 2.1, CompositeComponentAttributesELResolver#getType returned null when asked for the type, since it’s a read only resolver.

For JSF 2.2 this is replaced with an algorithm that first checks if the base is an ExpressionEvalMap and if so simply gets the value expression from that and asks it for its type. Then the metadata for the composite component is consulted to see if there’s a type being set for the given attribute (this corresponds to the type attribute on the cc:attribute tag). Finally, if a type is found via the metadata it’s only used if the type obtained from the value expression is either null, or if the metadata type is more specific (narrower).

Commits for this feature have been done between 20/jul/11 and 10/aug/11.

Java API

FaceletFactory in the standard API (spec issue 611)

JSF has a facility for obtaining factories for various things via the FactoryFinder. Even though Facelets is a standard part of JSF since 2.0, the FaceletFactory could not be obtained this way as it was an implementation detail.

In JSF 2.2, the status of Facelets as a default technology within JSF has been given another boost by making this factory obtainable from the FactoryFinder and moving it to the API part of JSF. The factory is obtainable via the constant FactoryFinder.FACELET_FACTORY (javax.faces.view.facelets.FaceletFactory).

Commits for this feature have been done on 15/sep/11 and the associated issue has been marked as resolved.

FlashFactory and FlashWrapper (spec issue 1071)

Next to the FaceletFactory, another new factory obtainable via the FactoryFinder in JSF 2.2 is the new FlashFactory. This factory can be used to create Flash instances.

Obtaining those instances was already possible before JSF 2.2 via ExternalContext#getFlash and this will remain the default way for ‘normal’ user code. The fact that there’s now a standard factory underneath means that there’s a hook available for overriding and/or wrapping the default implementation. This mechanism is explained here.

The factory is obtainable via the constant FactoryFinder.FLASH_FACTORY (javax.faces.context.FlashFactory).

Overriding it in faces-config.xml can be done as follows:

1
2
3

>
    >com.example.MyFlashFactory>
>

In addition to a factory, a new convenience wrapper class for the Flash, FlashWrapper has been added. Similar to existing wrapper classes like ViewHandlerWrapper, ExceptionHandlerWrapper, etc this allows one to wrap an existing Flash instance and selectively override methods.

Commits for this feature have been done on 16/feb/12 and the associated issue has been marked as resolved.

Instantiating composite component in Java (spec issue 599)

JSF 2.0 introduced the concept of the composite component: a component that is created via an .xhtml template instead of Java code. Even though the composite component is defined in .xhtml, it’s a first class component and ends up in the component tree as a Java component.

Up till now however there wasn’t any official API to instantiate a composite component as a Java instance via user code. So when building a component tree programmatically (see e.g. Authoring JSF pages in pure Java), incorporating those composite components was challenging to say the least.

JSF 2.2 will provide an explicit API for this.

Commits for this feature have been done between 02/oct/11 and 04/oct/11 and the associated issue has been marked as resolved.

Support for the Collection interface in UIData (spec issue 479) (mentioned in JSR)

From the beginning of JSF, the UIData component (known from e.g. ) only realistically supports the List, native array and JSF specific DataModel as input for its value binding*. This means other collection types always have to be expressed as any of these types. While this is not particular difficult, it’s a tedious thing to do and makes the code more verbose.

This issue has a rather long history, but it’s now finally addressed.

JSF 2.2 will introduce a javax.faces.model.CollectionDataModel in which UIData wraps an incoming value if it’s of type Collection. Collection is one of the last types being checked, so if the incoming value is a List the ListDataModel takes precedence.

The following are now the supported types:

null (becomes empty list)
javax.faces.model.DataModel
java.util.List
java.lang.Object[]
java.sql.ResultSet
javax.servlet.jsp.jstl.sql.Result
java.util.Collection new!
java.lang.Object (becomes ScalarDataModel)

Commits for this feature have been done on 31/jan/12 and the associated issue has been marked as resolved.

* java.sql.ResultSet and javax.servlet.jsp.jstl.sql.Result are officially also supported, but it seems usage of those are rather rare in practice. Also, only DataModel is internally supported, other types are automatically adapted into a DataModel.

Wrapper class for Lifecycle

In JSF many parts of the framework can be replaced by user supplied versions. Those versions can either completely replace the existing functionality, or can do this partially. For this the decorator pattern is utilized, where the user supplied implementation gets a reference to the existing implementation and can delegate functionality that it doesn’t want to replace to that.

To make this easy, JSF offers a bunch of wrapper classes; ViewHandlerWrapper for ViewHandlerWrapper, StateManagerWrapper for StateManager, etc.

Until now there wasn’t a wrapper class for LifeCycle. In JSF 2.2 there now is, with the predictable name LifeCycleWrapper

This small feature didn’t had a separate JIRA issue, but was committed as part for the work for spec issue 949.

Commits for this feature have been done on 23/feb/12.

Lifecycle

Identify client windows via a Window Id (spec issue 949)

Arguably one of the biggest problems that has been plaguing web application development since its inception is the inability to distinguish requests originating from different windows of a single browser. Not only has an actual solution been long overdue, it has taken a long time to realize this even was a problem.

The root of the problem, as always, is that the HTTP protocol is inherently stateless while applications in general are not. There is the concept of a cookie though, which is overwhelmingly the mechanism used to distinguish requests from different users and to implement things like a session scope where on its turn the bulk of login mechanisms are based on.

While a cookie does work for this, it’s global per browser and domain. If a user opens multiple tabs or windows for the same domain then requests from those will all send the same cookie to the server. Logging in as a different user in a different window for the same website is thus not normally possible, and having workflows (involving post-backs, navigation) in different windows can also be troublesome because of this.

In JSF there are various solutions that are somehow related to this. The view scope effectively implements a session per window as long as the user stays on the same page and does only post-backs. The Flash is used for transferring data between different pages (presumably within the same window) when navigation is done via Redirect/GET. There’s a wide variety of scopes implemented by third parties that do something similar.

All of these have some implicit notion or assumption of the concept of a ‘client window’, but there is no explicit API for this.

JSF 2.2 will introduce support for two different aspects of this:

Identification of an individual window: the Window Id
API and life-cyle awareness of the window concept

The first item unfortunately cannot be implemented perfectly, as ultimately only the HTTP protocol can do this. HTTP/2.0 might indeed do this, but it will be some time before that will be available. JSF will do a best-effort though and might allow users to easily plug-in their own implementation if they so desire.

Since no method to identify a window is perfect, the user can configure the preferred method in web.xml via a context parameter:

>
    >javax.faces.WINDOW_ID_MODE>
    >field> 
>

The current draft implementation supports only field and none which is the default. Additional anticipated values are script and url.

The window Id currently consists of the session Id (JSESSIONID) followed by separator and a sequential number, e.g. 953FAAGhGhYF78:1. The draft uses a hidden field with the name “javax.faces.WindowId”.

There are various places where the window concept will appear in the API, but most visible will be the new class ClientWindow and the method to obtain it: ExternalContext#getClientWindow().

The JavaDoc for ClientWindow mentions the following:

The lifetime of a ClientWindow starts on the first request made by a particular client window (or tab, or pop-up, etc) to the JSF runtime and persists as long as that window remains open. A client window is always associated with exactly one UIViewRoot instance at a time, but may display many different UIViewRoots during its lifetime.

Note that Window Id nor ClientWindow implement a new scope, but are instead a basis on which existing and new scopes can be portably implemented.

Components

Component modification management (spec issue 984)

In JSF, components can introduce variables in a kind of “component scope” or “component context”. The var attribute of iterating components like UIData or UIRepeat is a well known example of this. E.g.

 value="#{someBean.items}" var="item">
    
>

In JSF 2.1 and before there is no explicit API that components can use to manage this context. This is potentially troublesome for components that need to do a full tree visit within a clean context.

To assist with managing this context, JSF 2.2 will introduce a ComponentModificationManager that can be obtained via a call to FacesContext#getComponentModificationManager

Although details are scarce at the moment (only an API draft has been committed), it’s possible the API might be used by components as follows:

public boolean visitTree(VisitContext visitContext, VisitCallback callback) {
    ComponentModificationManager manager = visitContext.getFacesContext().getComponentModificationManager();
 
    ComponentModification modifications = manager.suspend(visitContext.getFacesContext());
    try {
        return super.visitTree(visitContext, callback);
    } finally {
        manager.resume(visitContext.getFacesContext(), modifications);
    }
}

(This is a rather advanced feature that the average JSF application developer will not likely come in contact with.)

Commits for this feature have been done on 16/dec/11.

XML configuration

Case insensitivity for state saving method (spec issue 1010)

In JSF one can set whether state is saved on the server or on the client via the context parameter javax.faces.STATE_SAVING_METHOD in web.xml which can be set to “server” or “client”. The values had to be used exactly as given. Using “Client” or “CLIENT” would actually result in server state saving being used. As of JSF 2.2 the value is made case insensitive, so those preferring to use “Client” can now do so.

Commits for this feature have been done on 26/may/11 and the associated issue has been marked as resolved.

Standards compliance

Unique ids and fixed name attribute for view state field (spec issue 220)

For keeping track of state associated with forms, JSF implementations write a hidden input field in each form that’s used on a page.

In JSF 1.2 this field was standardized and the specification demanded that both the id and name attributes were set to javax.faces.ViewState*.

The rule however breaks “W3C XHTML 1.0 Transitional” and above standards compliance. Namely, per that standard the id attribute should be globally unique within a document. If the JSF spec mandates that it should always have a fixed value, it clearly can’t be unique if multiple forms are being used on a single page.

Very early on, Mojarra introduced the parameter com.sun.faces.enableViewStateIdRendering, that when set to false simply omitted rendering the id attribute (thus leaving only the name present). Since this is an implementation specific parameter, not all third party libraries necessarily take its effects into account.

Therefor from JSF 2.2 on only the name attribute is mandated to have the fixed name. JSF 2.2 compatible libraries wanting to do something with the viewstate now have to work with a name-spaced Id (like other ‘normal’ elements in the markup rendered by JSF), or do lookups based on the name name attribute if they want to continue using the fixed name.

For now, Mojarra has removed the com.sun.faces.enableViewStateIdRendering parameter completely, so setting this explicitly to true will not bring the id attribute back.

Commits for this feature have been done on 30/jan/12 and the associated issue had initially been marked as resolved, but was re-opened on 06/feb/12 because of complexities involving the notorious troublesome Portlets environment and a new commit was done on 09/feb/12. See the EG discussion for more details.

*In addition the spec strongly recommends, though doesn’t enforce, that the value of this input field is difficult to predict in order to prevent cross site scripting attacks, see Cross Site Request Forgery protection for more details.

Allowing id attribute on all elements for HTML5 content (spec issue 1100)

Contrary to previous HTML standards, it’s allowed in HTML5 to use an id attribute for every kind of element.

In JSF 2.1 and earlier, the id attribute on the head was not being rendered. In case HTML5 content is being served, JSF 2.2 will render the id attribute for this element. For previous versions of HTML this is not done. Additionally, the VDL docs were updated and now state that for the body element an id attribute is rendered as well (this already happened, but the docs didn’t mention it).

Incidentally, a nice tidbit of information that we learned from this issue is that in JSF 2.2, HTML5 will be the default.

Commits for this feature have been done between 14/may/12 and the associated issue has been marked as resolved.

That’s it for now! I’ll periodically update this page when new information comes in.

Keep in mind that there are quite some interesting other things under discussion or even in development for possible inclusion in JSF 2.2. Such development is only currently taking place outside of the JSF trunk, which is the focus of this article. For instance see the discussion about a Window-id which is prototyped in MyFaces/CODI where a proposal is being setup as well, or the one about a multi-templating system (skinning), which is prototyped by lamine ba and mentioned by spec lead Ed Burns in an interview (among with several other interesting things, like HTML5 support).

Arjan Tijms

Sample CRUD application with JSF and RichFaces

Mark van der Tol — Fri, 30 Mar 2012 13:01:05 +0000

During my thesis project I will be using JavaServer Faces. Therefore it is important I get familiar with the framework. To get familiar I made a small CRUD (Create Read Update Delete) application. It is a simple application that makes it possible to keep track of users. It consists of a user list, a page to add/edit users and a page to delete a user.

The code

The research project will focus on when it is beneficial to use client-side scripting instead of/complementary to server side programming. To get up to speed a small CRUD application has been made without the use of client-side scripting and the same CRUD application was adapted to use client-side scripting by using RichFaces. The client-side scripting was added to the editing form to allow validating the form, without the need of making requests to the server.

The structure of the source project is as follows:

backing

Index.java – Backing for index.xhtml
UserDelete.java – Backing for UserDelete.xhtml
UserEdit.java – Backing for UserEdit.xhtml

constraints

Email.java – Validation annotation for fields. Fields with this annotation are validated to be a proper email address.
EmailConstraintValidator.java – Performs the validation for email addresses.

UserDAO.java – Data Access Object for users.

entities

User.java – Bean object for a user. The fields of this object are annotated with validators.
UserConvertor.java – Converts a userId to a user.

util

Messages.java – Utility object that helps with sending messages between pages.

The following JSF pages are in the project:

index.xhtml – Page with a list with all users
user_delete.xhtml – Page used to confirm whether a user should be validated
user_edit.xhtml – Page used for adding and editing users

While creating this application, I tried as much as possible to adhere to best practices. For examples, to go from the master (list) view to the detail (edit) view a GET request is used with the user id as parameter. The user is modified via POST and there’s a redirect and GET back to the master view (PRG pattern).

Both applications make use of Enterprise Java Beans, Bean Validation and Java Persistence API. EJB is used to inject persistence in the managed beans. Bean validation is used to ensure the data is consistent with the business rules.

In the RichFaces version user_edit.xhtml is updated to have client-side validations. Only the email address cannot be validated on the client. For that field is Ajax used.

The code of the project has been uploaded to Google Code so it can viewed by everyone. The code without the use of client-side scripting is put in the default branch and the code with client-side scripting is put in the RichFaces branch.

Demo

The compiled applications have been uploaded to OpenShift. It makes showing your work to the public very easy. This is a free cloud platform which runs a JBoss server. The projects can be directly uploaded from Eclipse to the OpenShift server. The live demo can be viewed here.

To upload your project yourself to OpenShift it is first required to make an account at OpenShift. Then register your public key at OpenShift. When you have the OpenShift plug-in installed in Eclipse you can add the OpenShift server to the server view in Eclipse. From there you can get the default project from OpenShift. This project is only used to send the war files to server, not to hold the code. By adding the JSF project to the OpenShift server it automatically places the war file in the OpenShift project during a publish. By pushing the OpenShift project to the server using GIT, the application is put in the cloud and is ready to use. The detailed process to upload to OpenShift from Eclipse is available here.

So wrapping up, I’ve made a small project to get familiar with the code, I have uploaded the code to Google Code and I’ve put the application OpenShift.

Mark van der Tol

Automatically setting the label of a component in JSF 2

arjan tijms — Thu, 22 Mar 2012 12:18:11 +0000

In JSF input components have a label attribute that is typically used in (error) messages to let the user know about which component a message is. E.g.

Name: a value is required here.

If the label attribute isn’t used, JSF will show a generated Id instead that is nearly always completely incomprehensible to users. So, this label is something you definitely want to use.

Of course, if the label is going to be used in the error message to identify said component, it should also be rendered on screen somewhere so the user knows which component has that label. For this JSF has the separate component, which is typically but not necessarily placed right before the input component it labels.

The problem

The thing is though that this label component should nearly always have the exact same value as the label attribute of the component it labels, e.g.

 for="username" value="Username" />
 id="username" value="#{myBean.username}" label="Username" required="true" />

There’s a duplication here that feels rather unnecessary (it feels even worse when the label comes from a somewhat longer expression, which is typical for I18N). My co-worker Bauke identified this problem quite some time ago.

Finding a solution

It appears though that an implementation that automatically sets the label attribute of the target “for” component to the value of the outputLabel isn’t that difficult, although there are a couple of things to keep in mind.

For starters, a component in JSF doesn’t directly have something akin to an @PostConstruct method in which you can set up things. There are tag handlers and meta rules in which you can set up attributes, but when they execute not all components have to exist yet.

Luckily, we always have the plain old constructor and since JSF 2 components can register themselves for system events. This gets us into a method where we can setup things.

Additionally, we have to be aware of state. System event listeners are luckily not stateful, so perfectly suited for tasks that need to be setup once (Phase listeners are stateful though, and will ‘come back’ after every postback). Attributes of a component are by default stateful, so we only need to set those once, not at every postback. Finally, the API distinguishes between deferred expressions (value expressions) and literals. If we want to support dynamic labels and only want to setup the wiring once, it’s important to take this distinction into account.

Finally, when searching for the target “for” component we can take advantage of the fact that typically this component will be close by. Compared to the regular search on the view root, the well-known “relative-up/down” search algorithm is probably more efficient here. This algorithm will start the search in the first naming container that is the parent of the component from where we start our search in the component tree. This will work its way up until there are no more parents, and if the component then still isn’t found (practically this is rare if the component indeed exists), then a downward sweep will be done starting from the root.

So, this all comes down to the following piece of code then (slightly abbreviated):

@FacesComponent(OutputLabel.COMPONENT_TYPE)
public class OutputLabel extends HtmlOutputLabel implements SystemEventListener {
 
    public OutputLabel() {
        if (!isPostback()) {
            getViewRoot().subscribeToViewEvent(PreRenderViewEvent.class, this);
        }
    }
 
    @Override
    public void processEvent(SystemEvent event) throws AbortProcessingException {
 
        String forValue = (String) getAttributes().get("for");
        if (!isEmpty(forValue)) {
            UIComponent forComponent = findComponentRelatively(this, forValue);
 
            if (getOptionalLabel(forComponent) == null) {
                ValueExpression valueExpression = getValueExpression("value");
                if (valueExpression != null) {
                    forComponent.setValueExpression("label", valueExpression);
                } else {                    
                    forComponent.getAttributes().put("label", getValue());
                }
            }
        }
    }
}

After creating a tag for this component, the following can now be used on a Facelet:

 for="username" value="Username" />
 id="username" value="#{myBean.username}" required="true" />

If a form is posted with this in it and no value is entered, JSF will respond with something like:

Username: Validation Error: Value is required.

An implementation of this is readily available in the new OmniFaces library, from where you can find the documentation and the full source code.

Arjan Tijms

How to run the Mojarra automated tests

arjan tijms — Sun, 26 Feb 2012 17:21:01 +0000

The JSF RI implementation Mojarra comes with a very extensive test suite. There are some instructions available on how to actually run those tests, such as the entry “How do I run the automated tests?” in the official FAQ and the document “TESTING_A_BUILD.txt” at the root of the Mojarra repository.

Both sets of instructions are not overly detailed and they don’t seem to be entirely up to date either. For instance, the entry in the FAQ states the following:

This target will cause the JSF API and implementation to be deployed to the GlassFish server
that is downloaded as part of the build process

This however doesn’t happen for testing JSF 2.x anymore (there was code that downloaded GlassFish V2 for JSF 1.x, but this can’t be used for 2.x).

The TESTING_A_BUILD.txt document mentions:

Be sure to install glassfish with a password on admin
make sure that password.txt is found in container.home

But how do we install glassfish with a password? If GlassFish is distributed as a .zip there is no install script, and the version with an installer also doesn’t offer any option to specify a password. I guess that there once was an option in the installer for this but it seems to have been removed since. Additionally, the password.txt in container.home appears to be not entirely correct.

After some trial & error I got the tests to run (more or less, read below). For my own reference and in the hope it’ll be useful to someone, I’m jotting the instructions down here.

Download GlassFish 3.1.1 from http://glassfish.java.net/downloads/3.1.1-final.html (I choose the zip archive).

Unzip GlassFish somewhere; we’ll call the resulting directory [glassfish home] below. This will look something like:

glassfish3 <--- [glassfish home]
    bin
    glassfish
    javadb
    mq
    pkg

The tests assume a password is being used, so we're now going to set one:

cd into [glassfish home]/bin and execute the following command:

./asadmin start-domain domain1

On Mac OS X this may take a minute due to a reverse DNS lookup being attempted (there's a fix).

After GlassFish has started, execute the following command:

./asadmin change-admin-password

Press enter twice and enter adminadmin for the password as below:

Enter admin user name [default: admin]> (press enter)
Enter admin password> (press enter)
Enter new admin password> (enter adminadmin)
Enter new admin password again> (enter adminadmin)
Command change-admin-password executed successfully.

Most commands in the test suite that interact with GlassFish use a password file (--passwordfile option), but for some reason not all. For those an additional .asadminpass file is required to be in the home directory of the user as whom the tests are run. This can be created via the following command:

./asadmin login

Press enter once and again enter adminadmin for the password as below:

Enter admin user name [default: admin]> (press enter)
Enter admin password> (enter adminadmin)
Login information relevant to admin user name [admin]
for host [localhost] and admin port [4848] stored at
[/home/youruser/.asadminpass] successfully.
Make sure that this file remains protected.
Information stored in this file will be used by
asadmin commands to manage the associated domain.
Command login executed successfully.

You can shutdown the container now using the following command:

./asadmin stop-domain domain1

Mojarra has recently gone from being distributed as 2 jars to 1 jar. The Glassfish 3.1.1 that you downloaded still uses 2 jars. In the past the test code patched GlassFish, but probably in anticipation of GlassFish shipping with 1 jar this no longer happens. In the mean time, it's necessary to patch GlassFish yourself.

In [glassfish home]/glassfish/domains/domain1/config/default-web.xml and [glassfish home]/glassfish/lib/templates/default-web.xml remove the entries jsf-api.jar and jsf-impl.jar and replace them by a single javax.faces.jar. I.e.:

Replace

jsf-api.jar
jsp-impl.jar
jsf-impl.jar

With

javax.faces.jar
jsp-impl.jar

Make a backup of the resulting [glassfish home] directory now. The test suite occasionally corrupts GlassFish and you often need to restore a fresh version. In fact, to have reliable test results you might opt to use a fresh GlassFish for every test run.

The Mojarra tests depend a lot on Maven, so if haven't installed Maven then install it now. E.g. on Ubuntu:

sudo apt-get install maven2

(This is not needed on OS X, since it already comes with Maven)

Now we're ready to check out the Mojarra source code. I'll assume SVN knowledge here.

Check out: https://svn.java.net/svn/mojarra~svn/trunk

We'll rever to the directory where you checked out those sources as [source home] below. E.g.

Mojarra <--- [source home]
    jsf-api
    jsf-ri
    jsf-tools
    [...]
    password.txt
    build.properties.glassfish
    [...]

Prior to starting the tests, a few files need to be customized. First, put the following in [source home]/password.txt:

AS_ADMIN_PASSWORD=adminadmin

Now copy [source home]/build.properties.glassfish to [source home]/build.properties.

Set the following entries in the newly created [source home]/build.properties:

jsf.build.home=[source home]
container.name=glassfishV3.1_no_cluster
container.home=[glassfish home]/glassfish
halt.on.failure=no

For example:

jsf.build.home=/home/myuser/Mojarra
container.name=glassfishV3.1_no_cluster
container.home=/home/myuser/glassfish3/glassfish
halt.on.failure=no

If you haven't already set this up, define JAVA_HOME. This is typically not needed on OS X, but is needed on a e.g. a fresh Ubuntu installation. If you don't do this, Maven will let you think it can't find an artifact from a remote repository, while in fact it couldn't compile some source files.

Additionally set ANT_OPTS to allow more memory to be used. E.g. in Ubuntu (bash):

export JAVA_HOME=/opt/jdk1.6.0_31/
export PATH=/opt/jdk1.6.0_31/bin:$PATH
export ANT_OPTS='-Xms512m -Xmx786m -XX:MaxPermSize=786m'

Now we're *almost* ready to run the build and the test. Unfortunately the Mojarra trunk seems to have a circular dependency between the clean and main targets at the moment. To break this dependency, comment out two ant tasks in [source home]/jsf-test/build.xml (as of writing on line 119):

Now cd to [source home] and execute the following command:

ant clean main

If you're lucky, the build will succeed without failures. Now undo the commenting in [source home]/jsf-test/build.xml, so the file will look like below again:


 dir="${api.dir}" target="main">
     name="skip.javadoc.jar"  value="true" />
>
 dir="${api.dir}" target="mvn.deploy.snapshot.local">
     name="skip.javadoc.jar"  value="true" />
>

cd to [source home] and execute the following command again:

ant clean main

If everything still went correctly, we can now run the tests. There are quite a lot of tests and running the suite till completion took 31 minutes on my 2.93Ghz i7 iMac and 48 minutes on an Ubuntu 11.10 installation running inside VirtualBox 4.1.8 on the same machine. The tests generate a whopping 1.6MB of logging, so if you want to scan it later you might want to divert it to a file:

ant test.with.container.refresh > ~/test.txt

If you want to follow the proceedings of the test run, you can use e.g. tail in a second terminal:

tail -f ~/test.txt

In my case, whatever I tried and however clean my system was, some tests were always failing. E.g. testFormOmittedTrinidad, TestLifecycleImpl, ScrumToysTestCase, AdminGuiTestCase.

Occasionally some tests don't honor the halt.on.failure=no setting that we did in the build.properties files. If this happens comment out the offending test. If you want to test your own changes to Mojarra, make sure to run the test suite a couple of times to get an idea of what tests are already failing for your system. I personally tried a couple of different machines and environments but none of them was able to pass all tests.

Finally, some extra information for Eclipse users. The tests can be run via Eclipse as well. If you initially check out the Mojarra project in Eclipse, you'll see a lot of errors. There are Eclipse project files, but they are obviously outdated (this is fixable, but I'll leave that for a next article). When working with Eclipse, you'll use Eclipse for editing the source code and for navigation (call references, navigate into and such). Even if the Eclipse project files are corrected, the actual compiler output will be thrown away.

To start the ant build via Eclipse, do the following:

Right click on build.xml, click Run As -> Ant Build… Go to the JRE tab and under VM arguments add the following:

-Xms512m -Xmx786m -XX:MaxPermSize=786m

On the same dialog go to the Environment tab and set JAVA_HOME to your installed JDK, e.g.
variable JAVA_HOME, Value /opt/jdk1.6.0_31 (this is not specifically needed on OS X or if you've already set JAVA_HOME globally for your system).

Go to the Targets tab and deselect everything. Then first select clean and then main. The target execution order in the bottom left corner of the dialog should list them in the right order. Having followed the instructions outlined above for command line ant (commenting out entries in [source home]/jsf-test/build.xml) now click Run. Follow the same instructions for restoring the file and again click Run. Finally, deselect both targets and select the test.with.container.refresh target.

Arjan Tijms

Eclipse 3.7 SR2 released!

arjan tijms — Fri, 24 Feb 2012 21:21:14 +0000

With once again an amazing release accuracy, today Eclipse Indigo Service Release 2, aka Eclipse 3.7.2 has been released.

In the core packages, some 89 bugs have been fixed.

Important projects that are part of the release train were updated as well, for instance WTP was updated from 3.3.1 to 3.3.2 (a fact not mentioned yet on the WTP homepage, but it can be found here). WTP 3.3.2 fixes no less than 112 bugs.

My personal favorite bug that has been fixed is 100% CPU for long time in ASTUtils.createCompilationUnit. Just having a fairly innocent page in your workspace would completely hang the CPU for minutes or more.

For the next version of Eclipse we’re supposedly going to get to see the 4.x line by default on the downloads page, so this might well be the last 3.x version that’s prominently featured on said page. Time will tell of course.

For now, Eclipse 3.7.2 can thus be downloaded from the usual place at http://eclipse.org/downloads and the general release notes can be found at http://www.eclipse.org/eclipse/development/readme_eclipse_3.7.2.html

Arjan Tijms

Passing null to the model in JSF

development — Wed, 08 Feb 2012 16:30:28 +0000

The problem

JSF allows you to bind an input component to a model bean via a so-called value binding. A notorious major headache is that a null is automatically coerced into a zero (0) when the bounded property is of type Integer or Long. This behavior only seems to rarely be the required one. A number of other types are coerced as well, e.g. in case of Boolean it’s coerced to Boolean.FALSE.

Finding a solution

Although coercing is a literal interpretation of the spec, it seems that basically only Tomcat that implements this somewhat peculiar behavior. They have a setting to turn this off:

-Dorg.apache.el.parser.COERCE_TO_ZERO=false

See e.g. jsf: integer property binded to a inputtext in UI is set to zero on submit

If you’re in a position to use this option, don’t read further and use it.

If you can’t use this option (you have e.g. a big system, lots of testing needed) and a null is needed at only a few places, another option is required. One possibility, that I will describe here, is based on a value-changed listener and a custom tag handler. What we do is breaking up the existing value binding of the input component in a base part and a property part, and then setting a null directly via the Apache BeanUtils library.

The following shows a TagHandler implementation that does this breaking up and installs a value-changed listener on the parent component:

public class MinusOneToNullConverter extends TagHandler {
 
    private static final Class[] VALUECHANGE_LISTENER_ZEROARG_SIG = new Class[] {};
    private static final String LISTENER_EL = "#{minusOneToNullListener.processValueChange(component, %s, '%s')}";
 
    public MinusOneToNullConverter(TagConfig config) {
        super(config);
    }
 
    @Override
    public void apply(FaceletContext ctx, UIComponent parent) throws IOException {
 
        String expression = parent.getValueExpression("value").getExpressionString();
        if (expression.contains(".")) {
            String base = expression.substring(2, expression.lastIndexOf('.'));
            String property = expression.substring(expression.lastIndexOf('.') + 1, expression.length() - 1);
 
            ExpressionFactory expressionFactory = ctx.getExpressionFactory();
 
            ((EditableValueHolder) parent).addValueChangeListener(
                new MethodExpressionValueChangeListener(expressionFactory.createMethodExpression(ctx, 
                    String.format(LISTENER_EL, base, property),
                    Void.class, VALUECHANGE_LISTENER_ZEROARG_SIG)
            ));
        }
    }
}

Note that the EL expression uses ‘component’ as the first parameter for the processValueChange method. This is an implicit EL object that refers to the current component being processed, which is in the case of this tag the parent component. Implementation wise it’s important to use the FaceletContext as the ELContext, instead of grabbing it from the FacesContext, when creating the method expression. Otherwise the context of the method expression would not be entirely correct and things like s will not be resolved.

The following shows the value-changed listener that will be installed:

@ManagedBean
public class MinusOneToNullListener {
 
    public void processValueChange(UIInput component, Object object, String property) throws AbortProcessingException {
 
        if (component.getValue() != null && component.getValue().toString().equals("-1")) {
            component.resetValue();
            try {
                PropertyUtils.setProperty(object, property, null);
            }
            catch (IllegalAccessException e) {
                throw new AbortProcessingException(e);
            }
            catch (InvocationTargetException e) {
                throw new AbortProcessingException(e);
            }
            catch (NoSuchMethodException e) {
                throw new AbortProcessingException(e);
            }
        }        
    }
}

As can be seen, the listener uses the input component to check if the value submitted was “-1″. The string representation is used here to be compatible with different types, although there are of course some other possibilities here. The listener will then reset the value of the component, so JSF will not attempt later on to push the -1 to our model object. Finally, bean utils is used to set the actual null value.

In this example, we used -1 to encode the desire for null. Other options might be feasible as well, such as the empty string or perhaps even null itself.

Before using this all, there is the tedious but mandatory registration of the tag handler in a *-taglib.xml file:

>
    >minusOneToNullConverter>
    >com.example.MinusOneToNullConverter>
>

Using the ‘converter’

After doing the above, we’re now ready to use this on a Facelet, e.g. :

 value="#{someBean.value}">
     />
     itemLabel="ALL" itemValue="-1" />
     value="#{data.somethings}" var="something" itemLabel="#{something.label}" itemValue="#{something.key}" />
>

Any other alternatives?

Once again, if on Tomcat, -Dorg.apache.el.parser.COERCE_TO_ZERO=false should be your first choice. If you use an application server that isn’t based on Tomcat, you also probably don’t need this. There’s a spec proposal open that asks to change this behavior, but despite a large amount of votes it hasn’t seen any activity for a long time.

Hopefully the hacky workaround presented here is helpful to someone.

Arjan Tijms

Easily disable sorting in PrimeFaces 3′s DataTable

development — Mon, 16 Jan 2012 17:42:04 +0000

PrimeFaces provides a convenient and easy to use sorting facility for its DataTable. Together with Facelets, this facility allows us to create re-usable columns that are natural sortable by default. E.g.:

 xmlns="http://www.w3.org/1999/xhtml" 
    xmlns:h="http://java.sun.com/jsf/html"
    xmlns:ui="http://java.sun.com/jsf/facelets" 
    xmlns:p="http://primefaces.org/ui"
>
     headerText="#{headerText}" sortBy="#{value}">
         id="#{id}" value="#{value}" />
    >    
>

Such a column can be used on a page inside a DataTable as follows:

1	id="foo" value="#{someBean.someValue}" />

The problem

The above is only a simple example, and real-life usage can be more complex with e.g. default styles and cell editing capabilities added. With such complex tags, it might be desirable to turn off sorting for certain columns programmatically. By default this does not seem to be possible in PrimeFaces. Setting the value attribute in the above example to null or the empty string via an expression prevents sorting, but still renders the sorting icon.

The reason for this is that the PrimeFaces renderer (org.primefaces.component.datatable.DataTableRenderer) checks for the presence of a value expression to determine whether the icon should be rendered, regardless of whether this expression evaluates to something non-empty. So nothing you pass into the value attribute of the above showed tag can make the value expression itself null, nor can any extra attribute accomplish this in the tag’s definition.

Custom helper tag

One solution is to build a simple helper tag that takes a parameter and based on that sets the value expression of its parent component to null. This tag can be nested inside a column. Taking it one step further, we can nest the tag inside a table and programmatically disable sorting on all columns. The following shows the implementation of such a tag:

public class ColumnSorterDisabler extends TagHandler {
 
    public ColumnSorterDisabler(TagConfig config) {
        super(config);
    }
 
    @Override
    public void apply(FaceletContext ctx, UIComponent parent) throws IOException {
        Boolean disableSorting = getRequiredAttribute("disableSorting").getBoolean(ctx);
        if (disableSorting) {
            if (parent instanceof Column) {
                parent.setValueExpression("sortBy", null);
            } else if (parent instanceof DataTable) {
                for (UIComponent child : parent.getChildren()) {
                    if (child instanceof Column) {
                        child.setValueExpression("sortBy", null);
                    }
                }
            }
        }        
    }    
}

After declaring this in a *-taglib.xml, we can use it as follows inside a Facelets tag:

 xmlns="http://www.w3.org/1999/xhtml" 
    xmlns:h="http://java.sun.com/jsf/html"
    xmlns:ui="http://java.sun.com/jsf/facelets" 
    xmlns:p="http://primefaces.org/ui"
>
     disableSorting="#{disableSorting}" />
 
     headerText="#{headerText}" sortBy="#{value}">
         id="#{id}" value="#{value}" />
    >    
>

We can now disable sorting on a per-column basis as follows:

1	id="foo" value="#{someBean.someValue}" disableSorting="true" />

or for an entire table:

 value="#{someBean.someValues}" var="something">
     id="foo" value="#{something.foo}" />
     id="bar" value="#{something.bar}" />
     disableSorting="true" />
>

One caveat to remember, TagHandlers exist only at ‘build-time’, so when using expressions to do the disabling the data these point to has to be available during build-time.

The f:attributes tag

Another solution, contributed by my co-worker Bauke Scholtz, is taking advantage of the tag. This tag does the same thing as an actual tag attribute, but contrary to an actual attribute this one can be conditionally excluded using . In that case the implementation of our re-usable column becomes this:

 xmlns="http://www.w3.org/1999/xhtml" 
    xmlns:h="http://java.sun.com/jsf/html"
    xmlns:ui="http://java.sun.com/jsf/facelets" 
    xmlns:p="http://primefaces.org/ui"
>
     headerText="#{headerText}">
         test="#{empty sortable or sortable}">
             name="sortBy" value="#{value}"/>
        >
         id="#{id}" value="#{value}" />
    >    
>

Notice how the tag attribute sortBy has been replaced by a child tag. This approach is really convenient since it simply uses JSF’s build-in functionality. To disable sorting for all columns at once, the helper tag based approach is still useful though. Note that just like the helper tag, a tag only exists at build-time, so here too only data that’s available during that time can be used.

Arjan Tijms

Passing action methods into Facelets tags

development — Fri, 06 Jan 2012 00:14:40 +0000

The problem

JSF, via Facelets, has various mechanisms to easily reuse view content. One of those is the Facelets tag, which allows one to reuse markup and/or components.

One notorious problem with these Facelets tags is that you can’t directly pass action methods (method expressions) into them. There’s a workaround where you break the expression into two parts, the base (which should be a value expression) and the name of the method as a plain string. Inside the tag these two are then combined again, e.g. via the array notation syntax. See e.g.

Another approach is to create a small helper tag that converts the value expression in some way into a method expression. There have been a couple of implementations of this idea:

Creating composite controls with JSF and facelets
How the button is created and how it acts (see ActionMapperTagHandler at the bottom of the page)

Finding a solution

In this blog I would like to present another variant on the tag handler idea, which doesn’t require nesting the content and also doesn’t parse any embedded EL expression manually. It supports EL parameters provided by the calling view. It’s not perfect however, since it does not support parameters being passed into the method from the target component (e.g. an ActionEvent for an actionListener).

The idea is to wrap the value expression (which represents the original method expression passed into the Facelets tag) inside a custom method expression. This method expression simply gets the value from the embedded value expression, which as “side-effect” executes this method.

The resulting method expression has to be stored somewhere. The request scope would be an option, but then it would be directly available outside the Facelets tag, which isn’t a good example of encapsulation.

An alternative is the javax.el.VariableMapper, a “magic” little thing that is able to scope value expressions to the duration of a Facelets tag (it’s magical since remember that the tag doesn’t exist any more after the component tree has been build). This however requires a value expresion again, so in an odd twist we wrap the method expression that we just created in a value expression again.

So, how can this work? Wasn’t the entire point of this exercise to go to a method expression? Well, as it turns out a value expression can be accepted wherever a method expression is required, iff this value expression directly returns a method expression.

E.g. the Apache EL implementation’s org.apache.el.parser.AstIdentifier contains the following code fragment that accomplishes this:

// case A: ValueExpression exists, getValue which must
// be a MethodExpression
VariableMapper varMapper = ctx.getVariableMapper();
ValueExpression ve = null;
if (varMapper != null) {
    ve = varMapper.resolveVariable(this.image);
    if (ve != null) {
        obj = ve.getValue(ctx);
    }
}
// (case B omitted)
if (obj instanceof MethodExpression) {
    return (MethodExpression) obj;
}

Code

Without further ado, here’s the code for the TagHandler that implements all the wrapping:

public class MethodParamHandler extends TagHandler {
 
    private final TagAttribute name;
    private final TagAttribute value;
 
    public MethodParamHandler(TagConfig config) {
        super(config);
        this.name = this.getRequiredAttribute("name");
        this.value = this.getRequiredAttribute("value");
    }
 
    public void apply(FaceletContext ctx, UIComponent parent) throws IOException {
        String nameStr = name.getValue(ctx);
 
        // The original value expression we get inside the Facelets tag, that's actually the method expression passed-in by the user.
        ValueExpression valueExpression = value.getValueExpression(ctx, Object.class);
 
        // A method expression that wraps the value expression and uses its own invoke method to get the value from the wrapped expression.
        MethodExpression methodExpression = new MethodExpressionValueExpressionAdapter(valueExpression);
 
        // Using the variable mapper so the expression is scoped to the body of the Facelets tag. Since the variable mapper only accepts
        // value expressions, we once again wrap it by a value expression that directly returns the method expression.
        ctx.getVariableMapper().setVariable(nameStr, ctx.getExpressionFactory().createValueExpression(methodExpression, MethodExpression.class));    
    }
 
}

The rather trivial adapter that wraps the value expression is shown below. The main method of interest here is invoke(). Note how unfortunately the params parameter has to be ignored.

public class MethodExpressionValueExpressionAdapter extends MethodExpression {
 
    private static final long serialVersionUID = 1L;
 
    private final ValueExpression valueExpression;
 
    public MethodExpressionValueExpressionAdapter(ValueExpression valueExpression) {
        this.valueExpression = valueExpression;
    }
 
    @Override
    public Object invoke(ELContext context, Object[] params) {
        return valueExpression.getValue(context);
    }
 
    @Override
    public MethodInfo getMethodInfo(ELContext context) {                
        return new MethodInfo(null, valueExpression.getExpectedType(), null);
    }
 
    @Override
    public boolean isLiteralText() {
        return false;
    }
 
    @Override
    public int hashCode() {
        return valueExpression.hashCode();
    }
 
    @Override
    public String getExpressionString() {
        return valueExpression.getExpressionString();
    }
 
    @Override
    public boolean equals(Object obj) {
        if (obj == this) {
            return true;
        }
 
        if (obj instanceof MethodExpressionValueExpressionAdapter) {
            return ((MethodExpressionValueExpressionAdapter)obj).getValueExpression().equals(valueExpression);
        }
 
        return false;
    }
 
    public ValueExpression getValueExpression() {
        return valueExpression;
    }
}

The tag handler has to be registered in a *-taglib.xml file, e.g.:

>
    >methodParam>
    >com.example.MethodParamHandler>
    >
        >name>
        >true>
        >java.lang.String>
    >
    >
        >value>
        >true>
        >java.lang.String>
    >
>

Using the tag handler

So the above takes care of implementing the converting tag handler. Let’s take a look at how we would use this.

Suppose we have a Facelets tag in the following using-view fragment, where the action attribute binds to a method in a backing bean taking an EL parameter:

1
2
3

 id="table" value="#{someBean.someValues}" var="someValue">
     action="#{someBean.delete(someValue)}" update="table" />
>

The tag could then be defined as shown below. The interesting bit is the tag, which converts the value expression “action” to the method expression “actionMethod”. The tag can be placed at many locations, but reasonable choices would be as the first child of the root or directly above the component using it. I choose the latter here.


    xmlns="http://www.w3.org/1999/xhtml" 
    xmlns:ui="http://java.sun.com/jsf/facelets" 
    xmlns:h="http://java.sun.com/jsf/html"
    xmlns:p="http://primefaces.org/ui"
    xmlns:my="http://example.com/my"
>
     styleClass="some_style">
 
         name="actionMethod" value="#{action}"/>
 
         id="someId" action="#{actionMethod}" process="@this" update="#{update}">
             value="/icons/delete.png" alt="#{i18n['something.delete']}" title="#{i18n['something.delete.tooltip']}" width="15" height="15" />
        >
    >
 
>

This Facelets tag too again has to be explicitly declared in a *-taglib.xml, e.g.:

>
    >deleteActionColumn>
    >faces/tags/deleteActionColumn.xhtml>
    >			
        >action>        
        >javax.el.MethodExpression>
    >
>

Any other alternatives?

At first sight the composite component mechanism would seem to be an alternative, as it explicitly supports passing in method references. However, the composite component isn’t a true substitute for Facelets tags. Namely, it inserts a parent component in the tree instead of simply its content. This doesn’t work for tables, panel groups, and all other kinds of components that require children of a specific type or in a specific order to be present.

You can sometimes do some magic with composite components by using the componentType attribute (see e.g. JSF composite component binding to custom UIComponent), but this only gets you so far and sometimes you really simply need the raw body of a tag to be inserted into the using page.

Another alternative solution, arguably the one and only Real Solution™, is having this fixed by Facelets. Indeed, many years ago there was an issue created for this at the Facelets JIRA: http://java.net/jira/browse/FACELETS-263 with a similar issue even having a patch submitted for it: http://java.net/jira/browse/FACELETS-273. Unfortunately, neither of those issues ever got resolved.

Hopefully the alternative solution provided here is useful for those situations where the existing workarounds are not completely satisfactory. Do note again that the solution presented here is also not ideal, but seems to work nicely in a rather straightforward way for action methods that don’t use framework provided parameters, but can optionally take user supplied EL parameters.

Arjan Tijms