I don't think the DeploymentContext in GlassFish has much to do with deployment stages or deployment types. AIUI it's a metadata source about the deployment that GlassFish can use to introspect the deployment to see what files are deployed etc.
On 20 Jun 2011, at 12:02, Werner Keil wrote:
> Sounds good, thanks.
>
> The term DeploymentContext is at least used by Glassfish as seen in this example based on Weld, the CDI RI:
> http://svn-mirror.glassfish.org/glassfish-svn/branches/3.0.1-deployment-perf/web/weld-integration/src/main/java/org/glassfish/weld/DeploymentImpl.java
>
> Werner
>
> -------- Original-Nachricht --------
>> Datum: Mon, 20 Jun 2011 11:42:11 +0100
>> Von: Pete Muir <pmuir_at_bleepbleep.org.uk>
>> An: Werner Keil <werner.keil_at_gmx.net>, users_at_javaee-spec.java.net
>> Betreff: Re: [javaee-spec users] [jsr342-experts] Re: Re: Staging (was Re: Configuration)
>
>> 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
>>>
>>
>
> --
> NEU: FreePhone - kostenlos mobil telefonieren!
> Jetzt informieren: http://www.gmx.net/de/go/freephone