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