>>>>> On Mon, 04 Jan 2010 11:21:50 -0800, Jim Driscoll <Jim.Driscoll(a)Sun.COM&gt; 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 -- | ed.burns(a)sun.com | office: 408 884 9519 OR x31640 | homepage: | http://ridingthecrest.com/

On 01/05/2010 08:14 PM, Ed Burns wrote: >>>>>> >>>>>> On Mon, 04 Jan 2010 11:21:50 -0800, Jim >>>>>> Driscoll&lt;Jim.Driscoll(a)Sun.COM&gt;  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

> I think there are two unrelated issues. > > 1) Should one be able to

On 1/6/10 2:57 PM, Lincoln Baxter, III wrote: > I'd like to understand a little more about the objections to runtime > modification. I agree in that I don't think it would add much value, but > is the opposition of a technical difficulty or practical/philosophical > nature? I'd like to learn why people feel this way. Is it more of "it > goes against the intentended usage of ProjectStage" or more of "it would > be too hard for too little value?" Or something else? > > Just for my benefit. Thanks! > I believe it's more a matter of "too hard for too little value". Not that it's all *that* hard (AFAIK) - but it's annoying enough of a change that I'd like to see at least one compelling usecase before supporting it. It also may have a (slight) overhead cost, which in Production stage is a good argument against it. Jim

I've been hearing "appserver", but would the "Java EE Umbrella Spec" be > enough to bring this behavior to servlet containers? The last thing we want > is to create another thing that appservers provide, that servlet containers > do not. We still need ProjectStage to make it into the Servlet spec, > explicitly, in order to bridge that gap, right? Is that an accurate > assumption? > My position on this is that the whole idea of using a "servlet container" needs to go away. We need a more robust foundation for what we deem "minimal" in the Java EE world so that we can inherit things such as project stages. That's why I believe that the web profile (or perhaps even an even lighter profile) needs to be the foundation. A servlet container isn't anything in Java EE. It's not defined. It is just an implementation of a couple of specs which is not defined as a group anywhere in the Java EE platform. The web profile is that grouping (well, it's damn close to what servlet containers are). So the question really needs to be, do project stages apply to all profiles? And I think the answer is yes, it should be possible to set the stage at the container level of whatever hosts your profile.