On Sat, Jun 18, 2011 at 1:55 PM, Adam Bien <abien_at_adam-bien.com> wrote:
>
> On 17.06.2011, at 21:32, Bill Shannon wrote:
>
> Adam Bien wrote on 06/17/11 01:01 AM:
>
>
> On 16.06.2011, at 23:18, Bill Shannon wrote:
>
>
> Adam Bien wrote on 06/14/2011 10:15 PM:
>
>
> On 14.06.2011, at 22:45, Bill Shannon wrote:
>
>
> Adam Bien wrote on 06/14/11 12:13 PM:
>
>
> On 13.06.2011, at 22:48, Bill Shannon wrote:
>
>
> We discussed this "staging" concept quite a bit internally for EE 6.
>
> In the end we left it out of the platform because it didn't seem to
>
> solve any problem that couldn't already be solved using other existing
>
> mechanisms, at least as it was being proposed at the time.
>
>
> We found *very* few cases where the behavior of existing APIs would
>
> change based on what "stage" you were in. About the best we came up
>
> with was that some web application errors might want to produce more
>
> useful output when in development stage. But since we specify very
>
> little about what such output should contain, products already have
>
> the flexibility to vary their behavior in this regard.
>
>
> If the behavior of the platform APIs don't change based on the stage,
>
> what is it used for? Well, applications could change their behavior
>
> based on the stage, but they can already do that using an appropriate
>
> JNDI environment variable of their own choosing; we didn't really need
>
> to specify that.
>
>
> But then you will have to change the application code. With stage dependent
> application server settings you
>
> would modify the application server settings, without touching the
> application.
>
>
> Well, you have to change the application code to read the variable and
>
> make use of it, but once you do that you can set different values of
>
> the variable without changing the application.
>
>
> I meant: you do not have to change the application to move it from one
> stage to another.
>
>
> So then we agree that using JNDI environment variables to hold the stage
>
> means you do not have to change the application to move from one stage
>
> to another, right?
>
>
> Except that JNDI is ugly for that :-). Injecting a Stage class and asking
> it about the current stage (it could come from JNDI) would be more
> appealing.
>
>
> @Resource(lookup = "deploymentStage")
> String stage;
>
> Use the admin tools of the container to set deploymentStage
> to whatever you want.
>
> Doesn't seem that ugly to me.
>
>
>
> Better:
> @Resource
> Stage activeStage;
>
> enum Stage{
> TEST, DEVELOPMENT, INTEGRATION, PRODUCTION
> }
>
> Any thoughts?
>
>
>
>
>
That is just a different name for the JSF2 enum. Far too inflexible for the
real word, not to mention the cloud.
Unless we use some form of Interface-decoration (see Josh Bloch's book)
allowing additional stages, or apply the parts of CDI dedicated to
DeploymentContext, using a string seems more flexible.