Adam,
In fact, I've never come across an admin that wants anything to do with
application configuration (even resetting log levels :-)). I hope we
define a minimum set of features with that scenario in mind. The
features that we do have I hope we can make them more developer-centric
(such as database and JMS resource definition).
I have mixed feelings about the staging bit overall though. I agree with
Bill that there is not a very prominent need for it. The needs that are
there can be handled by most build/deployment tools/CDI @Alternatives I
think. I was not even that sure what the compelling motivation for JSF
projects stages were to begin with. I'd like to see real world use-cases
outlined before we prioritize this/delve into this deeper. Surely this
was done already for JSF/CDI?
Cheers,
Reza
On 6/14/2011 3:13 PM, Adam Bien wrote:
> 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.
>> One idea we did consider was to have different resource settings based
>> on the stage. You might bind to one database for testing and another
>> for production, for instance. Since it's already possible for the
>> deployer to do these different mappings at deployment time, this seemed
>> like it would only really be useful if you could specify more details
>> about the resource you were mapping to, as you can with DataSourceDefinition.
> I actually never saw a dedicated deployer role in my projects. There is the "operation" role, but they usually
> do not care about the application internals.
>
> What is the experience of the other consultants (Antonio, Reza and Co:-))?
>
>
>> Allowing different resource configurations for different stages
>> required more changes to the deployment descriptors than we were
>> willing to consider for EE 6. Since we knew that we wanted to consider
>> major changes to deployment descriptors in the future, this was another
>> reason to defer defining anything about stages for EE 6.
> Or we could standardize the Resource settings (e.g. connection pools) on the application server side and make them stage dependent.
>> So, this may be something we want to consider for EE 7, along with other
>> improvements to resource configuration that may be required to better
>> support cloud deployment.
>
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1382 / Virus Database: 1513/3703 - Release Date: 06/14/11
>
>
>