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:

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.



The links for checkout or building do not work :(

Posted by Manfred Riem on February 16, 2008 at 12:44 AM PST #

It seems the GlassFish Wiki is currently down. Try again later in the day.

Posted by Ryan Lubke on February 16, 2008 at 02:16 AM PST #

I hope the automatically added '<h:messages' tag displays something like "Please add a '<h:messages' tag to your view" -- otherwise this will be a constant cause of confusion, as error messages will start disappearing when a product goes to production...

Personally, I would like this to include the possibility of pulling this value from the server itself -- from global JNDI, for example... this way, I can configure each of my servers in the appropriate way (my Development, SystemTest and Production environments are almost always different servers), and copy the same .war or .ear file from server to server -- is this something you're considering?


Posted by Matt Corey on February 16, 2008 at 10:42 PM PST #

So something like:

- If defined in JNDI namspace, then use that value, otherwise
- If defined in web.xml, then use that value, otherwise
- Default to ProjectStage.Production

I think that makes sense. I'll pass this on.

Posted by Ryan Lubke on February 17, 2008 at 01:34 AM PST #

Oh, regarding the h:messages - yes, that is what I was thinking as well.

Posted by Ryan Lubke on February 17, 2008 at 01:34 AM PST #

Yes, I think you've got it right -- this is related to what I think is one of the shortcomings of the Java EE 5 improvements that can be addressed in the future... the standard way of doing this configuration by changing the deployment descriptors isn't bad, but it just doesn't go far enough -- when I have a version of software that has passed QA, I want to take that exact .ear file and simply copy it to my production environment and not have to worry that I forgot to rebuild it properly or (even worse), needing to manually crack open the .ear file and change a file... if I could configure my servers properly via JNDI, and simply copy the same file over, it makes the deployment process much safer...

I've been meaning to blog on this for a while... perhaps it's time...


Posted by Matt Corey on February 17, 2008 at 01:44 AM PST #

Right, a WAR file really should be completely independent of production / QA or test deployment. I have blogged about how I currently do that at my own blog ;)

But to see this as feature included in JSF 2.0 would be superb!

Posted by Manfred Riem on February 17, 2008 at 02:35 AM PST #

Having a "development" mode in JSF is surely a good idea. I hope it is the first step to having a development mode in the app server. Right now, the single most unpleasant part of developing a JSF application is the "stack trace from hell", even more so than the "page that does nothing".

Of course, that's true for plain old JSP as well, but I think JSF needs to take a bigger role in fixing the problem. A JSP developer had to have a fair degree of (sophistication|masochism), but a JSF developer starts out dragging components into a form and then, without warning, falls into the tar pit of incomprehensible error messages.

Whenever an error has occurred, the JSF implementation needs to gather the file name/line number in the programmer's artifact and expose it to the development environment. The "stack trace" is not the appropriate mechanism for doing so.

Posted by Cay Horstmann on February 17, 2008 at 11:54 PM PST #

Hello Cay,

It's difficult to give line warnings in JSP (in the same way that facelets does it). That said, the EG is investigating alternate view technologies to JSF going forward which would hopefully address some of these issues.

Either way, I agree it needs to be improved.

Posted by Ryan Lubke on February 18, 2008 at 01:31 AM PST #

Matt - we've added the ability to configure ProjectStage via JNDI. I've updated the blog with details.

Posted by Ryan Lubke on February 19, 2008 at 03:36 AM PST #

I understand the rationale for wanting to weave h:messages into a component tree if it is missing when running under development mode. However, I have to say that this is a huge hack and shows a tremendous shortcoming in JSF. A far better approach would be to display a debug page like in Facelets if JSF determines it cannot render the message (because it is being silenced). Of course, then you need to have some way to indicate that you are purposely silencing errors on a page to avoid this behavior.

Can we think of a better example for the modes than this?

Posted by Dan Allen on May 12, 2008 at 05:42 AM PDT #

I think the h:messages is a valid example. That said, the resource handling implementation changes behavior depending on the mode. If development, no metadata caching will occur so the resource paths are computed with each resource request. If the mode is production, then the metadata is cached, and we spin up a background thread to monitor the resources for updates (this is all an implementation detail - the spec doesn't require it). If you're looking for more concrete spec based usages, no others have been baked in as of yet.

Posted by Ryan Lubke on May 12, 2008 at 04:31 PM PDT #

Ah, I like the resources example. That makes a lot of sense.

Another potential use of development mode is to enable a debug page similar to what Seam has. This page can be used to inspect the JSF runtime and the objects contained in the various stateful contexts. I find this page to be very useful and could even be extended through some sort of API or configuration.

Posted by Dan Allen on May 12, 2008 at 05:37 PM PDT #

If you are looking for a source of inspiration for the last suggestion (debug page), turn your head from Rails to PHP. I promise that you cannot wrestle the <?php phpinfo(); ?> utility page from a PHP developers hands. I realize that some of this information is provided by the application server, but do we really want to make excuses when the goal is to ease development and gain mindshare?

Posted by Dan Allen on May 12, 2008 at 05:40 PM PDT #

Sorry, that last question sounded defense. I meant for it to be suggestive. I'm sure we are all open to making development simpler ;)

Posted by Dan Allen on May 13, 2008 at 02:54 AM PDT #

A debug type of error page has been planned, just haven't had time to implement.

Posted by Ryan Lubke on May 13, 2008 at 05:46 AM PDT #

When are you planning to release JSF 2.0.Don't you think it is too slow.

Posted by Rahul Mahajan on May 22, 2008 at 01:59 AM PDT #

JSF 2.0 should mainly focus on component authoring to be made easy. Template approach for composite components.
Charting is no where in whole component set ?
Portlet and WSRP integration need to be focussed.
JSF 2.0 is in news for more than one year now, please tell us when should team expect something out.

Posted by Rahul Mahajan on May 22, 2008 at 02:04 AM PDT #

Rushing JSF 2.0 out the door would be a huge mistake. JSF 1.X was a decent start, but if 2.0 faces the same criticism, I'm afraid people will stop giving JSF a chance. Right now, we have the Mojarra enhancements, Seam, and Spring Web Flow being felt out for what is going to work for developers. Due diligence must be done.

Posted by Dan Allen on May 22, 2008 at 02:06 AM PDT #

I agree with you. JSF 2.0 needs to be best in the world, but still time to market in something which we should keep in mind.

Wood Stock 4.3 and Jboss Rich faces, Seam, Facelets are step in the right direction.

Skinning part should also be standardized.

More complex layout manager are needed even something simillar to html table will be the best gift.

More focus on client side functionality and Rich Internet Applications(RIA) is very critical moving ahead as lot of competition is on way.

I am sure JSF is the future and need to be kept in focus as JSP has limited life left.

Also don't think of reinventing wheel in all areas, leverage whatever is already existing (remember time to market is also a key).

Leverage the ide full power to avoid XML hell, create plugins for Netbeans 6.x to create components etc. This is the way out and the best way to market. Adobe comes with builder and Microsoft with their Studio. JSF team should also focus on reusing the power of Netbeans 6.x and avoid developers from internal complexities and other trivial things while focusing on writing simple API(use more annotations).

Architecturally I am confident this is the future, it just need right focus and positive energy

Investment in JSF is the key for SUN to be in web framework space.

Posted by Rahul Mahajan on May 22, 2008 at 02:25 PM PDT #

sorry for my bad English
i think that sun had con sacred more effort to javafx to make a rich client application to concurrens MS and Adobe i do not believe that it is a good idea not all the Web site need to video player or games to have fun.
I hope that the nearest version of jsf will inspired more from gwt (it is a good philosophie in some point but i like the jsf logique"beans,page folow")and setting more on the java script because webdevlopers are note like classics developers (c++,delphi,java se hahaha,c#)look at this (php,dojo,Dreamweaver) Rich clean interface a good wed dev language and a nice ide. the java community must make a tool regroup all this good point
and my final proposition
<h:commandButton id="button1" value="Submit" action="#{c1.f1(<i can put any parameter i want)}"/> without create my propre web Component

Posted by yac on May 25, 2008 at 10:19 AM PDT #

Good News is JSF 2.0 1st public draft is out!!. Check it for JSR 314 URL.

Component Authoring is in focus and composite component are now template oriented( Facelets) "EZComp".

With all energy lets review the specs and give feedback.

I hope skinning part can be more pluggable.

All component should support AJAX and messages and validations should be possible on client-side + server-side(AJAX).

Posted by Rahul Mahajan on June 03, 2008 at 02:40 PM PDT #

Hi, JSF 2.0 specs should try to focus on component JSON objects binding. Developers should work on JSON Proxy and framework injecting values into JSON proxies at run-time.

Component authors can write custom function in JSON binded beans and minimize the server calls.

This all thinking is key to making JSF 2.0 to be next generation specs and applications becoming more rich.

If JSF does not focus on this some other framework will do and surely it will be adopted by community.

All components should be light weight can be controlled client-side and server-side.

Everything has to be annotations based ( class-byte code instrumentation), no more XMLs and base classes please!!.

Charting support is nowhere ?? What kind of enterprise application are we thinking of in 2008.

I hope Java team plans to be very active in JSF 2.0 specs.

Posted by Rahul Mahajan on June 11, 2008 at 02:15 PM PDT #

[Trackback] We all know that Ryan Lubke is a top notch engineer, but did you also know he's a solid technical writer? Ryan has been posting plenty of really useful content on his blog about JSF 2.0, including the series on new features in JSF 2.0. This entry summ...

Posted by Ed Burns's Blog on June 26, 2008 at 07:00 AM PDT #

[Trackback] The Mojarra Project is proud to announce the release of the JSF 2.0 EDR1 implementation.

Posted by Jim Driscoll's Blog on June 26, 2008 at 07:08 AM PDT #

This is very similar to how JCatapult handles environments. However, we take a bit further and add something that web beans might allow down the road. We provide an injection point for the environment resolution API. This is pluggable so if you want to write your own environment system, all you need to do is register a different implementation of that interface and you are all set. By default, JCatapult uses a JNDI entry, but the possibilities are endless.

Posted by Brian Pontarelli on June 27, 2008 at 06:32 AM PDT #

IMHO there are enough more important shortcomings in JSF to address.
How about validators involving multiple components (form level/multi-field validation). A way to defeat the "Everything is a POST" critics (like Seam's page actions)?

If the automatic h:messages feature will really make it, I predict this it what will happen:
Most users won't change the ProjectStage anyway, so they still will be baffled about the non-functional forms.
Some developers will enable development mode and will then start to rely on the h:messages tag being present, so that the real problem will only be discovered after the app is in production and no longer includes a h:messages.

No, I don't want my app to behave differently. I want to test it exactly (or as least as close as possible) like it is going to be used in production.

Posted by Stephen Friedrich on July 02, 2008 at 07:48 AM PDT #

Why is the center of DTAP (Development Test Acceptance Production) Not incorporated in the javax.faces.application.ProjectStage enumeration?

Posted by jeroen dijkmeijer on August 07, 2008 at 04:43 PM PDT #

I sort of understand the need for some context like this. The H:message example is for me a way not to do it. If something goes wrong then that should never, ever be hidden. An error is easier to see then an empty place.

For resource handling I see more use. To me this seems more a task for your development environment. Maven, Ant, make, Eclipse...there are a million ways for me to figure out at what 'lifecycle' my app is. When I build it is when I care. So I don't quite see the usefullness of this feature. OTOH I don't see the harm either.

Posted by Jasper Floor on August 24, 2008 at 08:39 PM PDT #

[Trackback] The Mojarra Project is proud to announce the release of the JSF 2.0 EDR2 implementation.

Posted by Jim Driscoll's Blog on October 21, 2008 at 05:32 AM PDT #

Are there still plans to do the "debug error page" in Mojarra? If it's there, I don't see it when I set project stage = Development and I add some invalid EL to my page.

Posted by Stan Silvert on April 17, 2009 at 04:44 AM PDT #


How can I add JNDI resources in Glassfish v3 Prelude? It should be something simple, but apparently it's not :) I can only add JDBC resources...

Anyone knows why?

Posted by Wim Bervoets on April 26, 2009 at 07:25 PM PDT #

Tried out b46 promoted build of Glassfish; now there is a new admin command I can use:

asadmin create-custom-resource --factoryclass=com.sun
.faces.application.ProjectStageJndiFactory --restype=java.lang.String --property stage=Production javax.faces.PROJECT_STAGE

But I'm not sure how to add the property stage...

Posted by Wim Bervoets (javablog.be) on April 28, 2009 at 07:26 PM PDT #

Post a Comment:
Comments are closed for this entry.



« February 2017