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.