Oracle Blog

Adrift in the blogging sea...

Thursday Feb 14, 2008

This will be the first of a small series of blogs covering proposed new features in JSF 2.0.Keep in mind that none of the features described are final, and may change, butthis is a good opportunity to show the features as they exist now and illicit feedback.

We'll be starting to publish nightly builds of Mojarra 2.0.0 to the project site soon, but for the time being, you'll have to check out the sources and build the implementationyourself (luckily, the build is very easy).

So, what is the ProjectStage feature? In short, the JSF 2.0 EG has given a nod to Ruby on Rails' RAILS_ENV functionality.

At runtime, you can query the Application object for the configured valueby calling Application.getProjectStage(). The return value will be one of thedefined enums. If not explicitly configured, then the default will be ProjectStage.Production.

All of the values outside of Extension are fairly self explanatory, so what isExtension for? This allows the developer to leverage custom stages. So ifa value is specified that doesn't match the existing enumerate values, thenit will be the value for used. When calling Application.getProjectStage() theExtension enum value will be returned. Calling toString() on the return valuesat this point will return the value as configured in the web.xml. This will be useful for developers building upon the JSF framework to add stages to affect behavior that is outside the scope of the predefined types.

Overall the idea here is to be able to affect the behavior of JSF based on thesevalues. As an example of where this is useful: consider a simple JSF view thathas several validated input fields and validation fails. If there is no h:messagescomponent in the view, the page appears to do nothing. I can't tell you how many forum postings I've run across where this type of thing occurs, and the first response is always 'add h:messages to your view and try again'.

Here is where ProjectStage comes in: If the current stage is Development and no h:messages is present in the view, we'll add one automatically for the user. If the stage is Production we'd take no action (assuming the user would have this all corrected - no need to try to modify the tree).

While this feature may seem relatively minor, I wanted to discuss it first asit impacts the feature I'll be discussing in my next entry - stay tuned!

UPDATE: 2/19/2008 - JNDI configuration implemented

Per the feedback provided to this blog entry, we've implemented the ability toconfigure ProjectStage via JNDI. Then Application.getProjectStage() is firstinvoked, it will first check for a value from JNDI, if not found, it will then checkfor a context init parameter, finally defaulting to ProjectStage.Production if noconfigured value is found. The JNDI name that is currently spec'd isjava:comp/env/jsf/ProjectStage.

Additionally, we've added a JNDI ObjectFactory to Mojarra to make it easy fordevelopers to make a custom global JNDI resource to configure ProjectStage.

Here is an example of how to define this ObjectFactory in GlassFish:

The value of the stage property is what will be returned from the JNDI lookup.

It should be noted that mapping global JNDI resources to component resources(java:comp/env) is, unfortunately, an implementation specific process. So,to continue using GlassFish as an example, you'd need to add a resource-refentry to the web.xml: