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?
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.
> 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.
> 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?
> 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.
> 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).
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.
Kind regards,
Arjan Tijms