[jsr-314-open] [jsf2next] PROJECT_STAGE system property configuration

[Andy Schwartz]

Gang -

Cay Horstmann wrote:
> On 01/12/2010 12:58 PM, Ed Burns wrote:
>> Gah!  Cay is right, the spec does say the default is Production.  Either
>> 1) I'm not remembering things correctly, 2) the spec is wrong 3) I've
>> changed my mind since writing the spec.  In any case, this discussion is
>> apropos.
>
> If the spec is indeed not what you folks intended, maybe it would be a 
> good idea to fix it? This could be done independent of the larger 
> issue whether PROJECT_STAGE is adopted elsewhere in Java EE.

My colleague Blake Sullivan asked me to forward these along:

> I agree that we need to provide the best possible development 
> experience.  However, as enterprise software, we also want JSF 2 
> applications to be secure by default.  To that end, I believe that 
> production is the appropriate default PROJECT_STAGE.  Of course, during 
> development, we don't want to have to perform a bunch of additional 
> configuration in order to make the project stage during development, 
> Development.  However, our development tools should be able to do that 
> for us.  In addition, we really don't want the development tool to do 
> this by changing the init-parameter to Development, since there is 
> always the danger that we'll forget to change the value to Production 
> later and accidentally ship the application with the wrong 
> configuration.  We really want the development tool to configure the 
> project stage when deploying just to the development server.

While I understand and share the concerns that Cay and others have 
raised about developer experience, I also somewhat uncomfortable with 
changing the default project stage to development.  As Blake mentions, 
our development tools should be able to provide a reasonable 
experience.  It is possible that exposing a system property might make 
this somewhat easier to do - eg. the development tool could force the 
project stage to development when launching the development server.  
FWIW, I also think that the introduction of the ExceptionHandler and the 
requirement that all "unexpected" exceptions be routed through the 
ExceptionHandler should be a significant improvement, even when running 
in non-development project stages.

Andy