By user12615560 on 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, but
this 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 implementation
yourself (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.
javax.faces.application.ProjectStage provides the following options:
These values are configured via a context init-parameter like so:
<context-param>At runtime, you can query the Application object for the configured value
by calling Application.getProjectStage(). The return value will be one of the
defined enums. If not explicitly configured, then the default will be
All of the values outside of Extension are fairly self explanatory, so what is
Extension for? This allows the developer to leverage custom stages. So if
a value is specified that doesn't match the existing enumerate values, then
it will be the value for used. When calling Application.getProjectStage() the
Extension enum value will be returned. Calling toString() on the return values
at 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 these
values. As an example of where this is useful: consider a simple JSF view that
has several validated input fields and validation fails. If there is no h:messages
component 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 as
it 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 to
configure ProjectStage via JNDI. Then Application.getProjectStage() is first
invoked, it will first check for a value from JNDI, if not found, it will then check
for a context init parameter, finally defaulting to ProjectStage.Production if no
configured value is found. The JNDI name that is currently spec'd is
Additionally, we've added a JNDI ObjectFactory to Mojarra to make it easy for
developers 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-ref
entry to the web.xml:
Then you need to map the res-ref-name to the global JNDI resource via the
sun-web.xml (also in /WEB-INF/):
Alternatively, the JNDI configuration could be done by a simple env-entry
in the web.xml, but this doesn't allow you to configure ProjectStage for all
applications without modifying the web.xml.