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:
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 ProjectStage.Production.
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 java:comp/env/jsf/ProjectStage.
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.