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

[Dan Allen]

For the implementations, it might be a good idea to borrow the log message
the Wicket uses when running in development mode.

********************************************************************
*** WARNING: JavaServer Faces is running in DEVELOPMENT mode.    ***
***                                         ^^^^^^^^^^^          ***
*** Do NOT deploy to your live server(s) without changing this.  ***
*** See Application#getProjectStage() for more information.      ***
********************************************************************

(Of course, if we eventually settle on a platform-wide flag, then the
message can be updated appropriately).

Just something I noticed while working on a Wicket-related issue in Weld.

-Dan

On Wed, Jan 27, 2010 at 12:38 AM, Lincoln Baxter, III <
lincolnbaxter at gmail.com> wrote:

>
> We need to make sure we are clear whether the context parameter overrides
> the system property, or vice versa. I would think the system property would
> take precedence, but I'm open to counter arguments.
>
> Definitely need to flush out the solution of least surprise. I think that
> people will expect the system property to override web.xml - This would
> allow production servers to set the property and ensure that no matter what
> is deployed (accidents occur), they are *always* running in Production stage
> mode.
>
> At first thought, allowing web.xml to override the system property seems to
> allow greater flexibility, but in fact, it provides equal flexibility
> because you could simply leave your development stages at "Development" or
> whatever.. in web.xml, then disable the system-property when needed,
> allowing the same flexibility (as an inverse operation.)
>
> I am in favor of the System property overriding web.xml. I don't think it
> makes sense otherwise.
>
> --LB
>
>
> On Tue, Jan 26, 2010 at 6:32 PM, Dan Allen <dan.j.allen at gmail.com> wrote:
>
>> On Tue, Jan 19, 2010 at 5:03 PM, Andy Schwartz <andy.schwartz at oracle.com>wrote:
>>
>>> Ed Burns wrote:
>>>
>>>>  On Mon, 18 Jan 2010 15:16:20 -0500, Andy Schwartz <
>>>>>>>>> andy.schwartz at oracle.com> said:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>> AS>
>>>> https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=499
>>>>
>>>> AS> Can we add this to the MR list?
>>>>
>>>> Yes, but I'd like to get agreement that we don't care about the Servlet
>>>> EG's opinion on the VM-wide nature of system properties.
>>>>
>>>>
>>>
>>> Okay, thanks for the update Ed.  I wasn't aware that there had been push
>>> back from the Servlet EG on this.
>>>
>>> Personally I don't understand the nature of the objection.  In some case
>>> fine-grained (application-specific) control is desired.  We have addressed
>>> this case via the context parameter.  There seems to be general agreement in
>>> our EG that a system-level property would also be beneficial and in
>>> particular would improve the ease of use of this feature for
>>> development-time scenarios (ie. no need for a web.xml or JNDI config).  Not
>>> sure why we need to choose one approach vs. the other.  Both serve a
>>> purpose.
>>>
>>
>> The system property seems like a very reasonable option to me. It matches
>> well with "starting the server in debug mode" and I could even see the two
>> being tied together in an IDE server control (tangential to this decision,
>> of course). Just like with debug mode, this should be something that can be
>> controlled without a change to application code.
>>
>> We need to make sure we are clear whether the context parameter overrides
>> the system property, or vice versa. I would think the system property would
>> take precedence, but I'm open to counter arguments.
>>
>> -Dan
>>
>> --
>> Dan Allen
>> Senior Software Engineer, Red Hat | Author of Seam in Action
>> Registered Linux User #231597
>>
>> http://mojavelinux.com
>> http://mojavelinux.com/seaminaction
>> http://www.google.com/profiles/dan.j.allen
>>
>
>
>
> --
> Lincoln Baxter, III
> http://ocpsoft.com
> http://scrumshark.com
> "Keep it Simple"
>



-- 
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597

http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20100127/fed1a25f/attachment.html