It was actually called "DeploymentType" :-) You could define a new deployment type by creating an annotation, and meta-annotating with @DeploymentType (provided by the CDI spec)
The advantage of this over the String proposal is that it is typesafe and so will natively integrate with CDI, and not require some bridging layer like the older @Resource stuff. I would have thought that this is a primary requirement for anything we introduce?
On 19 Jun 2011, at 15:32, Werner Keil wrote:
> Some of us also looked at CDI for DeploymentContext. Also used by GlassFish btw, in "org.glassfish.api.deployment"
>
> Could help as inspiration, but as this will likely influence several JSRs, a solution best applicable to most seems what we're looking for.
>
> On Sun, Jun 19, 2011 at 1:53 PM, Adam Bien <abien_at_adam-bien.com> wrote:
>
> 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.
>
>
>
>
>
> --
> Werner Keil | UOMo Lead | Eclipse Foundation | Agile Coach, Principal Consultant | emergn limited
> 590 Madison Avenue. New York. NY 10022 | 68 Lombard Street. London EC3V 9LJ UK
> US Toll Free: +1-877.964.1981 | Worldwide Toll Free: +800.225.53482
> Twitter @wernerkeil | Skype: werner.keil | www.emergn.com | Reshaping IT
>