[javaee-spec users] Re: [jsr342-experts] report on EG meeting at JavaOne

From: Bill Shannon <>
Date: Fri, 04 Oct 2013 11:00:07 -0700

arjan tijms wrote on 10/04/13 05:24:
> > On slide 31 and 32 "ReST APIs to deploy and manage applications" and "ReST
> > APIs to monitor applications"
> >
> > It's perhaps interesting to remember that Java EE had an API/SPI here
> with JSR
> > 88 and JSR 77, but they were pruned for Java EE 7 (see e.g.
> >
> Right, do we believe they aren't used because they were poor APIs?
> Because they
> used the wrong technology? Will converting them to use ReST suddenly make
> them
> more attractive?
> I don't think the answers are clear.
> I very briefly looked into JSR 88 and to me it seems a lot of effort was
> wasted in providing interaction points with non-standard properties of an
> application server. Just starting and stopping a server, plus deploying and
> undeploying a simple application archive *seemed* to be regarded as a minor
> use case, while I think people expected that to be the most important one.
> See this old topic:
> and specifically
> the 3rd comment:
> "Given that, the spec must assume that the user needs to interact with the
> beans in order to specify their deployment information to the server. That
> would seem to leave Ant right out of the picture. "
> In 2002 things may have been different as I guess far less was standardized
> then, but I'm not entirely sure if this assumption would make much sense
> today. There's IMHO not much need for mandatory "deployment information".
> There's a .war, .jar, .ear etc and for the main use case that's it.
> Maybe it's worth it to look to Arquillian containers for this story, which
> abstract the same start/stop/deploy/undeploy functionality but in a seemingly
> more pragmatic way.
> ReST would only work for an already running server, so for starting the server
> there's still a non-ReST solution needed. But all in all, ReST can make the
> APIs more attractive. What I got from Arquillian discussions is that JSR 88
> was also troublesome from the tool vendor perspective, since it required
> linking to binaries. Linking to binaries frequently involves licensing issues
> (either incompatible open source licenses, or closed source/non-distributable
> jars like is the case for WebLogic). I think tool vendors try to avoid that.
JSR-88 was created when we still required a lot of mapping from application
resources to server resources, and that mapping was all done in product-specific
ways. We've since added more and more standard ways to handle these deployment
issues, so it's true that in many ways the problem is easier today, at least for
many common cases.

Managing applications seems doable. Controlling the server lifecycle is more
problematic. Especially looking ahead to cloud/PaaS support, the server
lifecycle might be controlled completely by the PaaS provider, with no way for a
customer/user to start or stop a server. Even just thinking of a simple cluster
environment, does stopping the server mean stopping the entire cluster, or just
one server in the cluster? There's enough issues here that this isn't
straightforward, and it might need to be optional since not all environments
will be able to or will want to support it.

> > Maybe it would also have been interesting to see what the votes would have
> > been with Oracle attendees included.
> We didn't want to skew the results; we were more interested in what others
> thought.
> I see. Where there also non-EG attendees that voted, or only EG members?
Non-EG members attended and were able to vote. I didn't keep track of who
actually voted.

> Maybe it would be interesting to see the distinction between EG/non-EG
> members, instead or Oracle/non-Oracle. Otherwise you maybe want to exclude
> JBoss attendees as well from voting where it concerns CDI, as they lead the
> CDI spec. Or am I missing the point here?
You're reading too much into this. It was just a straw poll to give us a rough
idea of what these experts were thinking. It was not a scientific or
statistically valid poll.

If anyone on this list wants to send me your 10 votes, I'll factor those in as
well. We're still just collecting informal data. We hope the community-wide
poll we plan to do will give us more representative data, but even then it's a
self-selecting audience and has to be interpreted in that context.

> And there seemed to be support for it during the discussion, but in the end no
> one voted for it. Sometimes you have to make difficult choices when you
> have a
> limited number of dollars to spend...
> I understand this more than anything (often have dealt with the same thing
> internally in my company). Hopefully the security topic can get some more
> support down the road though.
Maybe we'll see more interest when we do the community-wide poll.

Maybe it will take someone with a particular passion in this area to get it done
despite otherwise low interest.