arjan tijms wrote on 10/09/13 11:02:
> Hi,
>
> On Friday, October 4, 2013, Bill Shannon wrote:
>
> 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.
>
>
> 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.
It was pruned because virtually no one is using it.
> About this pruning process, the mailing list discussion regarding JSR 77
> proposed to make JSR 77 a candidate for becoming optional ("proposed
> optional") in Java EE 7, but eventually it became optional right away.
> There were no more follow ups to that discussion, so I wonder what changed.
JSR 77 is not optional. See table EE.6-1.
> Managing applications seems doable. Controlling the server lifecycle is
> more problematic.
>
>
> Maybe it's useful to define profiles for this?
>
> The local server/development use case seems pretty well understood for
> instance; it's what e.g. most Arquillian containers and Eclipse WTP server
> runtimes implement.
>
> Starting/stopping a local server and deploying/undeploying a single
> application archive (including exploded archives) to this local server without
> any need to come into contact with more advanced features such as remote
> deployments, cluster environments, server specific configuration/mappings etc
> would surely be a great and useful feature to have for a variety of developer
> focused tasks.
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.
> 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.
>
>
> True, although the customer/end-user may not be the only user of a server.
> Even if a server is only accessible via PaaS by the end user, a system admin
> may still be able to do deployments locally, maybe just for a local test
> install. Perhaps even the TCK could use the same deployment APIs to test a
> server for compliance. I assume that eg SAP Netweaver was tested for
> compliance via some kind of local install, wasn't it?
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.
>
>
> 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.
>
>
> Things like support for clustering are probably hard to be mandated if
> clustering itself isn't mandated by Java EE. Yet, what is the value of a spec
> if too many things are optional? From my brief look into JSR 77 and 88 I got
> the impression that one of their issues was that too much is optional.
I'm not sure that's a major issue with either of those specs. But yes, in
general, a spec will lots of optional pieces is less useful and harder to use.
>
>
> Maybe it will take someone with a particular passion in this area to get
> it done despite otherwise low interest.
>
>
> I'm personally passionate about this subject and have submitted a number of
> related issues, but I'm not myself a real security expert. To really align
> security in a new overal framework would also require cooperation from a
> number of other specs (eg from the Servlet and EJB people).
Yup.
> The alternative perhaps is not going for a comprehensive framework, but keep
> doing small incremental changes such as the programmatic login that was added
> in Servlet 3.0 and the * role in Servlet 3.1/EJB 3.2 and JACC. With the
> typical pace that Java EE moves in this will mean we're easily talking about a
> decade (~3 releases) to get any amount of work done, but even those small
> changes each release do help a lot.
We're definitely open to that, and will consider the filed Jira issues in that
context.