Find JSRs
Submit this Search

Ad Banner

Summary  |  Proposal  |  Detail (Summary & Proposal)  |  Nominations
JSRs: Java Specification Requests
JSR 373: JavaTM EE Management API 2.0

Stage Access Start Finish
Withdrawn   29 Nov, 2016  
Expert Group Formation   24 Nov, 2015  
JSR Renewal Ballot View results 10 Nov, 2015 23 Nov, 2015
JSR Review Ballot View results 09 Dec, 2014 22 Dec, 2014
JSR Review   25 Nov, 2014 08 Dec, 2014
Status: Withdrawn
Reason: Withdrawn at the request of the Spec Lead.
JCP version in use: 2.10
Java Specification Participation Agreement version in use: 2.0

This JSR is to update JSR 77 with REST interfaces and incorporate deployment as a standard part of the management interface.

Expert Group Transparency:
  Public Project Page
  Public Communications
  Issue Tracking


Specification Leads
  Martin Mares Oracle
Expert Group
  Adam Bien ConSol GmbH
: Roland Huss
ConSol GmbH
: Fabian Stäber
: Chris Vignola
: Martin Mares
Red Hat
: Kabir Khan

This JSR has been Withdrawn
Reason: Withdrawn at the request of the Spec Lead.

Updates to the Original JSR
The following updates have been made to the original proposal:

The schedule has been updated:
Q4 2015 Early Draft
Q1 2016 Public Review
Q3 2016 Proposed Final Draft
H1 2017 Final Release

Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1. Identification

Submitting Member: Oracle

Name of Contact Person: Martin Mares

E-Mail Address:

Telephone Number: +420 221438282

Fax Number: +351 21 423 51 00

Specification Lead Member: Oracle Corporation

Specification Leads: Martin Mares

E-Mail Address:

Telephone Number: +420 221438282

Fax Number: +351 21 423 51 00

Initial Expert Group Membership:


Supporting this JSR:

Java User Group Macedonia (JUGMK)

Individual supporters:
Mite Mitreski (JUGMK)
Antonio Goncalves
Michael Remijan

Section 2: Request

2.1 Please describe the proposed Specification:

JSR 77, "J2EE Management," defines a set of managed objects that must be provided by the Java EE platform using defined Management EJB interfaces. Each instance of a managed object is identified by a structural OBJECT_ID. Managed objects can also implement one of the following interfaces to provide additional functionality: EventProvider, for distribution of configuration events; StatisticsProvider, for monitoring support; and StateManageable, for basic lifecycle control.

The goal of the proposed specification is to supersede the current Management EJB APIs and define new REST-based interfaces for describing managed objects. It should increase the interoperability and usability of the new interface, thanks to the wide pallet of existing HTTP tools and libraries. The expert group should also consider whether the existing MEJB and JMX APIs should be designated as Proposed Optional -- with the goal of simplifying the specification and increasing its value and chances of adoption, both by implementers and third party clients.

New REST interfaces will require the transition or completion of the currently used OBJECT_NAME to a URL, as well as the definition of CRUD operations over the individual managed objects. These steps represent the core of the new specification. Server-Sent Events will be used for event support (EventProvider), but WebSockets will be also considered. SSE is the currently preferred solution over WebSockets because it can be read by most of the current existing HTTP tools; it does not require HTTP upgrade; and it is unidirectional, simple to parse and human readable.

JSR 88, "Java EE application deployment," defines interfaces for the development of custom deployment tools. These tools must be installed directly on an individual Java EE server before their first usage. Support for JSR 88 has been made optional as of Java EE 7.

Deployment will be included directly into the management REST interface. It will be possible to use this interface directly to deploy an application without the requirement to install the deployment module to the application server instance. Application deployment can be done using the same interface as relevant resource definition and management. The new deployment interface will focus on simple deployment use cases first. If complex cases are covered, then this will be done in a way that does not require knowledge of complex deployment support for the execution of simple cases.

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

Java EE 8 or higher

2.3 The Executive Committees would like to ensure JSR submitters think about how their proposed technology relates to all of the Java platform editions. Please provide details here for which platform editions are being targeted by this JSR, and how this JSR has considered the relationship with the other platform editions.

This is a major update of JSR 77 J2EE Management. It is targeted for Java EE 8.

2.4 What need of the Java community will be addressed by the proposed specification?

The need for the usage of standard HTTP tools for management of Java EE application servers.

2.5 Why isn't this need met by existing specifications?

The existing JSR 77 specification defines only Management EJB and JMX interfaces.

2.6 Please give a short description of the underlying technology or technologies:

REST (Representational State Transfer) is an architectural pattern for interface definition in distributed hypermedia systems such as HTTP.

2.7 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

TBD (Most likely no java interfaces will be defined.)

2.8 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?


2.9 Are there any security issues that cannot be addressed by the current security model?


2.10 Are there any internationalization or localization issues?

This JSR will use the I18N support in Java SE.

2.11 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

This is an update of JSR 77, and it will also cover some features of JSR 88 (optional as of Java EE 7).

2.12 Please describe the anticipated schedule for the development of this specification.

Q3 2014 Expert Group formed
Q1 2015 Early Draft
Q3 2015 Public Review
Q4 2015 Proposed Final Draft
Q3 2016 Final Release

2.13 Please describe the anticipated working model for the Expert Group working on developing this specification.

The primary means of communication will be email with the support of conference calls.

2.14 Provide detailed answers to the transparency checklist, making sure to include URLs as appropriate:

Q: Is the schedule for the JSR publicly available, current, and updated regularly?
A: Yes, the schedule will be available on the project page for the JSR at

Q: Can the public read and/or write to a wiki for the JSR?
A: Public mailing list will be used for comments,

Q: Is there a publicly accessible discussion board for the JSR that you read and respond to regularly?
A: Public mailing list will be used for comments,

Q: Have you spoken at conferences and events about the JSR recently?
A: No.

Q: Are you using open-source processes for the development of the RI and/or the TCK?
A: The RI will be done under the open source GlassFish project at The TCK is not open source.

Q: What are the Terms of Use required to use the collaboration tools you have prepared to use with the Expert Group, so that prospective EG members can judge whether they are compatible with the JSPA?
A: The terms of use are available at

Q: What is the location of your publicly-accessible Issue list? In order to enable EC members to judge whether Issues have been adequately addressed, the list must make a clear distinction between Issues that are still open, Issues that have been deferred, and those that are closed, and must indicate the reason for any change of state.

Q: What is the mechanism for the public to provide feedback on your JSR?
A: The users' email list,

Q: Where is the publicly-accessible document archive for your Expert Group?

Q: Does the Community tab for my JSR have links to and information about all public communication mechanisms and sites for the development of my JSR?
A: Yes, it will.

Q: Do you have a Twitter account or other social networking feed which people can follow for updates on your JSR?
A: Yes, @MartinJMares. A project-specific handle can also be created if needed.

Q: Which specific areas of feedback should interested community members (such as the Adopt-a-JSR program) provide to improve the JSR (please also post this to your Community tab)?
A: Technical feedback for individual parts of the JSR is welcome.

2.15 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.

The reference implementation and TCK will be made available as part of the reference implementation for the Java EE 8 platform.

2.16 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).


2.17 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.

Proposed licenses will be the same as similar, previous specifications, such as JAX-RS 2.0 (JSR-339).

For reference, JSR 339 licensing was as follows:

Java EE Management 2.0 specification license

RI license

    Commercial use:
  1. The RI will be available for commercial use under the CDDL 1.1 open source license, the GPLv2 with Classpath Exception open source license, or this license.

  2. Non-Commercial use

    The RI will be available for non-Commercial use under the CDDL 1.1 open source license or the GPLv2 with Classpath Exception open source license.

TCK license

  1. Commercial use

    The Java EE 8 TCK will be available for commercial use under this TCK license.

  2. Non-Commercial use

    As required by the Java Specification Participation Agreement (JSPA), the TCK will be licensed at no charge without support to qualified not-for-profit. The Compatibility Testing Scholarship Program will verify such qualification. Support may also be provided at no charge with approval of the scholarship board. For more information, please refer to:

2.18 Please describe the communications channel you have established for the public to observe Expert Group deliberations, provide feedback, and view archives of all Expert Group communications.

The JSR's project will contain publicly available mailing lists, archives, and document download areas.

2.19 What is the URL of the Issue Tracker that the public can read, and how does the public log issues in the Issue Tracker?

2.20 Please provide the location of the publicly accessible document archive you have created for the Expert Group.

Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

JSR 77 (
JSR 88 (

3.2 Explanation of how these items might be used as a starting point for the work.

This JSR is a major update of JSR 77 including some features defined in JSR 88.