Reza/all,
Thanks for the suggestions.
We have a simple and blunt, but working Mavenized Use Case.
The "env" property is the enum-esque value in this case, used mainly during
build-time, but in theory this could also be used at run-time to look up
resources, etc.
[...]
<build>
<filters>
<filter>../conf/${env}.properties</filter>
</filters>
[...]
In addition to that Spring's *PropertyPlaceholderConfigurer *is also used
where applicable.
Cheers,
Werner
On Sat, Jun 18, 2011 at 1:40 AM, Reza Rahman <reza_rahman_at_lycos.com> wrote:
> Adam/et al,
>
> If all you are really looking for is a standardized JNDI name for an
> enum-esque value, I think that's doable without much issues. I guess you
> could set that value via a declarative (e.g. web, faces-config, beans,
> ejb-jar, etc XML) or programmatic API. The part I still don't get is the
> compelling problem that we are trying to solve that isn't easily/better
> solvable otherwise? Here is the ones I can see:
>
> 1. Mock objects - use CDI @Alternative and deploy the correct beans.xml via
> ANT, Maven, etc.
> 2. Resources - use build/deployment tools to solve it (in our case,
> deploying the correct resin-beans.xml with data sources/JMS resources via
> ANT/Maven).
> 3. Are there other common use cases?
>
> Even if we did allow setting the project stage per application, that would
> also likely need a specific deployment descriptor to be deployed at run-time
> anyway. In addition, it really bloats up the deployment descriptors that
> currently only have configurations for one "stage" to declaring
> configuration for all the stages in one place. I guess I'm really not
> understanding the benefit to be gained in the end?
>
> Don't get me wrong. For the most part, I'm playing devil's advocate to make
> sure we are not over-standardizing or prioritizing incorrectly. To me, at
> best this is something we can look into if we have time remaining after we
> solve the more serious issues that would help more, such as better internal
> alignment of the existing Java EE APIs and removing some of the existing
> warts that remain for developers to run into - particularly arising from the
> late introduction of CDI into Java EE 6 ( and we all know the reasons for
> that delay -- it had to do more with personalities, rivalries and politics
> rather than technology).
>
> Cheers,
> Reza
>
>
>
> On 6/17/2011 3:32 PM, 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.
>>
>>
>> -----
>> No virus found in this message.
>> Checked by AVG - www.avg.com
>> Version: 10.0.1382 / Virus Database: 1513/3709 - Release Date: 06/17/11
>>
>>
>>
>
>
--
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