Werner, I think you touch a point here : shall we define staging on our own
or let individual JSRs define and we just do the aggregation job ? Or going
depper in this topic : I think each individual JSR should be represented in
the umbreall EE group (but that's maybe for JPC.next).
We could kick off this topic within EE 7 and once we have more thoughts,
exchange them with the other JSRs
Antonio
On Tue, Jun 14, 2011 at 16:52, Werner Keil <werner.keil_at_gmail.com> wrote:
> Bill/all,
>
> Thanks for the update. As I mentioned some of the ideas being considered on
> a platform level, while others (e.g. that stage enum in JSF as a first step)
> where left to individual parts, how is it likely to work for EE 7? Should
> individual JSRs like JSF or CDI 1.1 look at this and exchange ideas or
> should that be dealt with more centrally?
>
> Another question is, whether the JSON JSR is likely to still become part of
> EE 7 or has it been postponed till 8?
>
> Some folks in current teams had some good results using annotations, both
> for JPA-like data-mapping and persistence but against non-relational
> content, as well as together with JSON actions and data types. Some of that
> could be worth considering for a JSR in either area.
>
> Werner
>
>
> On Tue, Jun 14, 2011 at 2:18 AM, Bill Shannon <bill.shannon_at_oracle.com>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.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>
>
>
--
Antonio Goncalves
Software architect and Java Champion
Web site <http://www.antoniogoncalves.org> |
Twitter<http://twitter.com/agoncal>|
Blog <http://feeds.feedburner.com/AntonioGoncalves> |
LinkedIn<http://www.linkedin.com/in/agoncal>| Paris
JUG <http://www.parisjug.org>