Reza + * :-),
I get more and more questions about staging. Furthermore all serious apps, especially with cloudy background, have to deal with staging.
Introducing an Injectable enum or Staging class would simplify the development and make staging better administrable through the admin console.
Currently dealing with JNDI is not that comfortable.
Btw. it is not a big deal to implement staging with Java EE 6, 5 or even 1.4, but we should reduce the common amount of code in Java EE 7...
thanks,
adam
On 17.06.2011, at 22:10, Reza Rahman 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
>>
>>
>
>