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

[Cay Horstmann]

On 01/05/2010 08:14 PM, Ed Burns wrote:
>>>>>> On Mon, 04 Jan 2010 11:21:50 -0800, Jim Driscoll<Jim.Driscoll at Sun.COM>  said:
>
> JD>  On 1/3/10 12:45 PM, Lincoln Baxter, III wrote:
>>> I'd like to revisit this for JSF2.1 -
>>> https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=499
>>>
>>> Project stage is something that needs to be configurable without
>>> modifying the underlying WAR (and while JNDI support is provided, it
>>> requires container configuration, admittedly not a huge downside.)
>>> However, for those who do not primarily use JNDI for configuration, a
>>> -D system property makes a lot of sense.
>
> JD>  That sounds like something that could be handy - please file an RFE.
>
>>> I'd also like to propose one other enhancement, which is runtime
>>> configuration of the PROJECT_STAGE through an exposed API. This is
>>> something that I think should be able to turn on and off while the
>>> server is running (For the same reason it must be possible to enable
>>> or disable debug logging or auditing at runtime.)
>
> JD>  That has performance implications - for instance, we do some setup of
> JD>  the application based on project stage that would be awkward to change
> JD>  on the fly.  Offhand, I'm not in favor of this change, since that
> JD>  complicates the runtime behavior for what must be a rather small corner
> JD>  case.  If you have a compelling use case, you might change my mind, but
> JD>  keep in mind that implementing this is not as simple as it may appear at
> JD>  first blush.
>
> I also am not in favor of this change.  We make a lot of assumptions
> about the immutability of the ProjectStage value at runtime.
>
> Ed
>

I think there are two unrelated issues.

1) Should one be able to change the project stage setting on the fly for 
a deployed application? Clearly, this is tricky since it affects caching 
etc., and I agree that it isn't an important use case.

2) Should there be a way of setting the project stage without touching 
web.xml? The usecase here would be for apps that can do without web.xml, 
which is increasingly likely as web fragments catch on. I talked this 
over with the GlassFish people a few months ago, and they were receptive 
to the concept of global parameters for all web apps, such as setting 
the project stage for all apps in a particular server instance.

Still, this points to the fact that the default for the project stage is 
probably wrong. For developers and students, not fussing with web.xml is 
very handy. At deployment time, it's an easy matter to add a web.xml, or 
a parameter in an existing web.xml, that sets the project stage to 
production.

Cheers,

Cay


-- 

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