arjan tijms wrote on 10/10/2013 10:46 AM:
> On Wed, Oct 9, 2013 at 8:17 PM, Bill Shannon <bill.shannon_at_oracle.com
> <javascript:_e({}, 'cvml', 'bill.shannon_at_oracle.com');>> wrote:
>
> arjan tijms wrote on 10/09/13 11:02:
>> Do you or anyone else remember what the exact rationale was for removing
>> JSR 88? I did some digging but couldn't find anything on the mailing
>> lists. If I understand correctly it was pruned in Java EE 6, made
>> optional in Java EE 7, and will be removed in Java EE 8, right?
> Nothing is ever removed from the RI. It's optional and will remain
> optional for the foreseeable future. Products may choose not to provide it.
>
>
> Thanks for the clarification. I was under the impression that the cycle was
> "prune" (announce becoming optional), "make optional", "remove from the spec",
> but this was thus wrong.
>
> It was pruned because virtually no one is using it.
>
>
> Aren't at least WebLogic and Geronimo using it as their native deployment API?
I'm sure they're *providing* it, but I have no idea if they're *using* it.
I believe WebLogic, like GlassFish, uses its own native APIs for deployment.
> But what I actually meant to ask is whether it's known why the uptake was so
> low? Was there any discussion about that back then?
There has been some discussion of this, but I don't have all the history, and
the original spec lead is long gone. My impression is that people simply found
it too complex, plus they didn't want to use a product-specific client-side jar
file to access this functionality. They want a simple, portable network
protocol, possibly with a portable Java API wrapper jar file.
> The functionality still seems to be in demand. As this sub-discussion started
> out with; will replacing it by ReST APIs suddenly make it something everybody
> will use?
There's the key question, isn't it? :-)
If lots of people want to write their own tools to do simple deployments, that
might be sufficient. But I fear that the people who would write their own tools
to do this would also want to write their own tools to do lots of other
administration/management operations and so the simple API might not be
sufficient; they might need to use product-specific APIs for lots of other
operations they want to do so the value of having a portable API/protocol for
just this part would be lower.
>
>
> Feel free to submit a new JSR to define such a spec. I agree that many
> would find it useful, but it's unlikely to become a required part of the
> platform.
>
>
> Do you mean the JSR corresponding to the item "ReST APIs to deploy and manage
> applications" from slide 31, or a JSR completely separate from that?
No, I was talking about a ReST API to manage application *servers*, e.g.,
shutdown, restart, etc.
A ReST API to manage *applications* would be an appropriate addition to the
platform, to replace JSR-88, assuming we came up with something that had
widespread support.
>
>
> The TCK needs to be able to deploy/undeploy applications, but it does not
> need to start/stop servers. The TCK has been using JSR-88, but with that
> becoming optional the TCK will need to define its own pluggability API
> just for its own purposes; it need not be a general purpose API.
>
>
> That's really interesting to know.
>
> I wonder, if this new ReST API did indeed happen and it only did
> deploy/undeploy, couldn't that one be used for the TCK?
Yes, it probably would. My point is that the TCK's requirements are more
limited than the requirements for a general API of that sort, so the TCK can
live with a more limited solution that wouldn't be acceptable for a standard API.
>
>
> I'm not sure that's a major issue with either of those specs.
>
>
> Well, I got this among others from the following quote in the "Pruning JSR-77"
> discussion that I referred to earlier:
>
> >> [...] forces the application server to expose a consistent set of monitoring data [...]
> > I'm not sure it does that with so much of the spec being optional
I'm not that familiar with JSR-77; you may be right, but it would be interesting
to hear fromoithers.
>
>
>
> We're definitely open to that, and will consider the filed Jira issues in
> that context.
>
>
> Great, that's a really good start. I especially hope that a few of the filed
> Jira issues for JASPIC can be done for Java EE 8 (either for another MR or for
> a new version of that spec).
We'll definitely consider them.