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?