On 19.06.2011, at 07:37, Werner Keil wrote:
>
> 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.
It was a first shot. We could even use a String, but we should standardize its JNDI-name and existence.