Agreed... As it stands, leaving ProjectStage set to Production and relying on tools to set it to Development is not a good experience for the developer. I think we rely too heavily on IDEs to support things that are "ugly" in the framework, like XML namespaces, nav-rules configuration (now fixed), and tag-libraries (granted those are pretty standard among frameworks these days.) The reason IDE's came in to being was to compensate for the increasing complexity of our systems, and present that complexity in a way that made more sense to humans, so keeping things simple is more important than ever.

However, I really think that access through a -Djavax.facesProjectStage=Development system property is simple, and understandable. It doesn't take much work to figure out how to use it, much less potentially confusing than configuring JNDI and it's mapping in web.xml. It makes IDE integration simple... you don't even need IDE plug-in support because you just add it as a JVM argument to your server's launch configuration; lots of tools do that. (Ant, Maven, JavaRebel, Grails, for example.)

The text guys are happy, too, since they do everything from the command line anyway.

I think we should keep this in our minds, even if a way to use JNDI in a plug-in-friendly way is found. Did we decide if this was too big to be included in the MR?

--Lincoln

PS. As a side-note. I've updated the Tutorial on www.javaserverfaces.org/getting-started to reflect the Development ProjectStage in web.xml. So by default, people following the getting-started tutorial will see up front that there is a control for the ProjectStage, and that we chose to show them the Development mode first. Four lines of XML is trivial to include in a tutorial, and also relatively self-explanatory.

On Mon, Jan 18, 2010 at 10:45 AM, Cay Horstmann <cay@horstmann.com> wrote:
On 01/14/2010 12:15 PM, Andy Schwartz wrote:

While I would prefer not to change the project stage default, I am
totally behind doing whatever we can to ensure a reasonable out of the
box experience. Development tools can certainly help here, but we should
all be vigilant about reporting/discussing/addressing cases where we
fall short of this goal.


Check out this blog that explains how to set the project stage globally with GlassFish. http://blogs.sun.com/rlubke/entry/jsf_2_0_new_feature2

This is NOT a good out-of-box experience.

I was hoping that I could just tell Ludo to make the JNDI setting in the Eclipse plugin, but that's not good enough. Note the super-ugly part two of the instructions where the JNDI name jsf/ProjectStage must be mapped to the name used in the GlassFish configuration.

Oh great--now I don't have to set the project stage in web.xml. Instead, I get to put twice as many lines of GlassFish-proprietary mumbo jumbo into web.xml. The whole reason I wanted this is to be able to ditch web.xml altogether for simple examples.

(Actually, I think you could do this with a sun-web.xml, but it's still ugly.)

How is JBoss doing here? Can I just click on a checkbox and set the JSF project stage to development?

Cay


--

Cay S. Horstmann | http://horstmann.com | mailto:cay@horstmann.com



--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"