On 10.10.2011, at 19:59, Bill Shannon wrote:
> Jason T. Greene wrote on 10/10/11 7:25 AM:
>> We skipped pruning JSR-77 last time around because a number of us thought it was
>> better to update it to be more current. I think it's become clear that the spec
>> is not only not going to be updated, but that its relevance is fading with the
>> cloud direction the industry is moving in.
>
> I agree, we're not expecting significant updates to JSR-77, and we need a
> different management API in the long term. I'd be much happier if we had
> a replacement in place when we make JSR-77 optional.
+1 the good thing about JSR-77 is that it forces the application server to expose a consistent set of monitoring data.
It is a major added-value over e.g. Plain Old Web Container...
>
>> Can we prune it this time around (make it optional to vendors)? Also, why does
>> the pruning process require that we wait for the next EE iteration to finalize
>> something being made optional? Let's assume that in this example we made JSR-77
>> optional in EE7, then after 7 is released we decided it was a mistake, we can
>> just bring it back as required in EE8.
>
> We adopted the process formalized by the Java SE platform expert group, rather
> than inventing our own different process. It's good that there's consistency
> across the Java platform for how these things are handled.
>
> The reason it takes two releases is to give developers and the community a
> chance to react and to provide feedback. This is fairly standard practice
> across the industry.