JSF 2.0 New Feature Preview Series: Part 1: ProjectStage
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:
- Production
- Development
- UnitTest
- SystemTest
- Extension
These values are configured via a context init-parameter like so:
<context-param>
<param-name>javax.faces.PROJECT_STAGE</param-name>
<param-value>Development</param-value>
</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 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:
<resource-ref>
<res-ref-name>jsf/ProjectStage</res-ref-name>
<res-type>java.lang.String</res-type>
</resource-ref>
Then you need to map the res-ref-name to the global JNDI resource via the sun-web.xml (also in /WEB-INF/):
<resource-ref>
<res-ref-name>jsf/ProjectStage</res-ref-name>
<jndi-name>javax.faces.PROJECT_STAGE</jndi-name>
</resource-ref>
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.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)





Comments
Carlos García replied on Thu, 2008/08/07 - 4:29am
So, according to your example, JSF may hide my errors during the "Development" stage and will show them in all their glory in the "Production" stage... I think that I don't want this.
I'm sure that the new feature is very useful, but i would like to have a better example. May be the error reports could be different in different stages showing more or less information.
Any more examples?
Carlos.
Yo Tu replied on Thu, 2008/08/07 - 5:11am
in response to:
Carlos García
You have read it the other way...
The idea is to add extra debug info in development mode (adding h:messages if not present) :P
Sergey Tyulkin replied on Thu, 2008/08/07 - 6:54am
Carlos García replied on Thu, 2008/08/07 - 11:54am
in response to:
Yo Tu
Ok, I understand now (I think). So the thing is to provide extra information in the development stage, which is what I like, but adding the means needed to show this information.
In this case I would like to have a warning saying something like this: "Hey dude! JSF has added this amazing h:messages TAG to be able to show you this great information. But remember that it will be added only during the development stage."
Does it make any sense to you?
Yo Tu replied on Sat, 2008/08/09 - 12:25pm
in response to:
Carlos García
Wim Bervoets replied on Mon, 2009/04/27 - 5:12am
Hi,
I'm trying to get the JNDI route working GlassFish v3 Prelude. However you can't seem to add JNDI Custom Resources via the console or via asadmin.
So how can I create a server-wide/domain-wide ProjectStage setting and let my app's use this?
To me it seems a simple task, but apparently it isn't :-(
Wim
hookfi john replied on Sun, 2009/05/31 - 9:01am
Howard Haines replied on Mon, 2010/10/25 - 3:17am