Re: [jsr-314-open] [jsf2next] PROJECT_STAGE system property configuration
On 01/05/2010 08:14 PM, Ed Burns wrote:
>>>>> On Mon, 04 Jan 2010 11:21:50 -0800, Jim
Driscoll<Jim.Driscoll(a)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@horstmann.com