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

Ed Burns Ed.Burns at Sun.COM
Mon Feb 8 11:43:23 EST 2010


>>>>> On Tue, 19 Jan 2010 17:03:08 -0500, Andy Schwartz <andy.schwartz at oracle.com> said:

AS> Personally I don't understand the nature of the objection.  In some case 
AS> fine-grained (application-specific) control is desired.  We have 
AS> addressed this case via the context parameter.  There seems to be 
AS> general agreement in our EG that a system-level property would also be 
AS> beneficial and in particular would improve the ease of use of this 
AS> feature for development-time scenarios (ie. no need for a web.xml or 
AS> JNDI config).  Not sure why we need to choose one approach vs. the 
AS> other.  Both serve a purpose.

EB> In fact, I'm on the phone with Bill Shannon, Roberto Chinnici, Rajiv
EB> Mordani, and the Sun EE architects right now for our weekly meeting.  I
EB> have requested a timeslot to bring this up (again) there.  I'm glad I'm
EB> on the phone because otherwise, I might get tomatoes thrown in my face.

AS> Wow, sounds harsh.  I guess I am missing why this is so
controversial.

I brought this issue to the Sun JavaEE Architecture meeting on Tuesday
19 January 2010.  This meeting happens mostly weekly and is where the
Sun EE Spec leads coordinate efforts to drive JavaEE spec efforts to
completion.  The technical leadership at this meeting includes Bill
Shannon, Sun Distinguised Engineer and past JavaEE spec lead, and
Roberto Chinnici JavaEE 6 spec lead.

I brought up two issues regarding ProjectStage

1. revive the drive to expose ProjectStage to lower level technologies
in EE.

2. have a System property to set the ProjectStage.

For 1), the following questions were raised:

* What specific use-cases exist for having ProjectStage at the servlet
  level?  If the Servlet EG reviewed the proposal and ultimately
  rejected it, why bring it up again?

* What about Gavin King's "alternatives" proposal?

  Pete Muir has clarified at this meeting that the "alternatives"
  proposal from Gavin did not make it into CDI in such a way as to be
  appropriate for our needs in the ProjectStage feature.

For 2), the following points were raised:

* There are no other System Properties in all of EE.  Why do we need one
  now?

* Why, specifically, does this system property need to be a part of the
  portable programming model?

  I voiced that it's useful in cases like mvn jetty run, or mvn tomcat
  run.  Bill countered that such usages are already container specific,
  so it would best be addressed with a container specific configuration.

In conclusion, I think we should close this spec issue and handle the
System Property at the impl level.  I have opened issue 1539 for this
case.  I will send a separate email regarding this issue.

>>>>> On Tue, 19 Jan 2010 17:07:13 -0500, "Lincoln Baxter, III" <lincolnbaxter at gmail.com> said:

LB> We should also probably decide and state that configuration defined in
LB> web.xml will override the system property.. or visa versa. Though I think
LB> the former allows more fine grained control.

LB> I am in favor of the System property overriding web.xml. I don't think it
LB> makes sense otherwise.

I agree also.

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

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

Yes, I've added that to the issue.


Ed
-- 
| ed.burns at sun.com  | office: 408 884 9519 OR x31640
| homepage:         | http://ridingthecrest.com/




More information about the jsr-314-open-mirror mailing list