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

[Matthias Wessendorf]

On Wed, Jan 6, 2010 at 6:15 AM, Cay Horstmann <cay at horstmann.com> wrote:
> 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.

+1
see my comment on the bug / issue for that setProjectStage();

>
> 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,

Well, the API supports JNDI already today;
However System Properties is handy; specially when you run an instance
of an app-server w/in a certain IDE
(on Oracle's embedded OC4J (in JDEV) we used to have a System property for that
"special" environment, which is most-likely not production (when you
run an app w/in
an embedded server, from an IDE)))

-Matthias

> 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
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf