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

[Matthias Wessendorf]

that's cool

On Wed, Jan 27, 2010 at 7:33 PM, Dan Allen <dan.j.allen at gmail.com> wrote:
> 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
>



-- 
Matthias Wessendorf

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