Find JSRs
Submit this Search

Ad Banner

JSRs: Java Specification Requests
JSR 333: Content Repository API for Java Technology 2.1

Updates to the Original JSR

The following information has been updated from the original proposal:


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

May 31 2013: Public draft submitted.
July 1 2013: Begin PR ballot period
July 31 2013: Proposed Final draft submitted.


Specification Lead: Peeter Piegaze, Adobe Systems Inc.

E-Mail Address:

Telephone Number: +33 6527 98199

Fax Number: -

Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1. Identification

Submitting Member: Day Software

Name of Contact Person: David Nuescheler

E-Mail Address:

Telephone Number: +41 61 226 98 98

Fax Number: +41 61 226 98 97

Specification Lead: David Nuescheler

E-Mail Address:

Telephone Number: +41 61 226 98 98

Fax Number: +41 61 226 98 97

Note that the Specification Lead has been updated from this original proposal.

Initial Expert Group Membership:

See JSR-283 EG.

Supporting this JSR:

See JSR-283 EG.

Section 2: Request

2.1 Please describe the proposed Specification:

Since this JSR represents an enhancement of JSR-283, which was itself an evolution of JSR-170, the same general goals apply to this JSR as to the JCR 1.0 and JCR 2.0 proposals.

The following functional areas will be reviewed by the expert group for possible inclusion in version 2.1:
(1) Ease of API use: Make simple, things simple.

(2) Lower entry barriers for implementers and application developers.

(3) Scripting support of the API.

(4) Client-server awareness.

(5) Protocol and SPI bindings. Binding and liaison to OASIS / CMIS.

(6) Maintenance and feedback container for implementers, users and non-users. Gauge real-world interoperability.

(7) Node type library.

(8) Internationalization.

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

The target platform is primarily server-based applications interacting with content repositories. Desktop platforms may be supported as well.

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 JSR is submitted to the J2SE/J2EE EC.

2.4 Should this JSR be voted on by both Executive Committees?

No. It should be voted on only be the J2SE/J2EE committee.

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

Since this JSR is the successor to JSR-170 and JSR-283 the issues addressed are the same (from the JSR-170 submission):

Today, (web) applications have to adapt to every vendor's proprietary API to interact with content repositories. This has the negative effect of locking a large percentage of information assets in vendor specific formats, limiting access to information, impacting system evolution/migration, and availability of third party content management tools. This API will examine solutions to these and other issues deemed important by the expert group.

There is no easy way to integrate content-producer-applications (CMS) and content-consumer-applications (CRM, Personalization, Portal, etc.) independently of the actual underlying content repository. The expert group will examine solutions to this problem also.

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

As the successor to JSR-170 and JSR-283 the issues that the expert group is going to review are extensions that that were not considered in JSR-170 or JSR-283 for timing and specification-size reasons.

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

Since this JSR is the successor to JSR-170 and JSR-283 the underlying technology is the same (from the JSR-170 submission):
The following functional areas will be reviewed by the expert group for possible inclusion:
Granular Read/Write Access - This is the bi-directional interaction of content elements. Issues with access on a property level and not just on a "document" level should be examined. A content transaction is any operation or service invoked as part of a system interaction with a content repository.
Versioning - Transparent version handling across the entire content repository, would provide the ability to create versions of any content within the repository and select versions for any content access or modification.
Hard- and Soft-structured Content - An Object Model that defines how hard and soft-structured content could be addressed will be examined.
Event Monitoring (Observation)- Possible use of JMS based notification framework allowing for subscription on content modification will be examined.
Full-text Search and filtering - The entire (non-binary) content of the repository could be indexed by a full-text search engine that enables exact and sub-string searching of content. The API will examine ways to standardize how content is queried, whether full-text or parametric. Of course, existing standard query languages will be respected.
Access Control - Unified, extensible, access control mechanisms will be examined. Standards such as JAAS or ACL standards shall be taken into account.
Object Classes - Profiles or Document Types could be defined and inherited to allow constraints and to give the application programmer the ability to operate on content object types.
Namespaces & Standard Properties - Defining default standard properties that will maintain namespace uniqueness and hierarchy will be examined.
Locking and Concurrency - Standardized access to locking and concurrency features of a repository will be examined.
Linking - A standard mechanism to soft/hard link items and properties in a repository along with providing a mechanism to create relationships in the repository will be examined.

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

javax.jcr and subpackages. Unchanged from JCR 1.0 & JCR 2.0.

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

This specification has no software or hardware dependencies outside of other Java Standards.

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


2.11 Are there any internationalization or localization issues?

Though one of the topics to be considered for this JSR is the issue of internationalization support in content repositories, there are no localization or internationalization issues that have to be taken into account for the standard itself.

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


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

Sep 2010: Early draft submitted.
Nov 2010: Early draft review closed.
Mar 2011: Public draft submitted.
May 2011: Public review closed.
Nov 2011: Proposed Final draft submitted.
Jan 2012: Final release.

NOTE that this information has been updated from this original proposal.

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

The specification will be authored in a collaborative development style, known from open source communities. The main means of communication are based on a mailing list, a weekly conference call and face-to-face meetings as required.

2.15 Provide detailed answers to the transparency checklist, making sure to include URLs as appropriate.

(1)  The public can read the names of the people on the Expert Group.
Yes, all active members that have contributed to the specification
are acknowledged as part of the spec document. Also due to the open
issues tracking everybody that has contributed in the form of of
issues reporting is publicly visible.

(2) The Expert Group business is regularly reported on a publicly readable alias.
Using the platform there is a publicly visible update on the
status of the jsr and the meeting minutes available for interested parties.

(3) The schedule for the JSR is publicly available, it's current, and I update it regularly.
The schedule will be updated as needed both on the update page and
also on the details page and currently exposes the latest version on the
JSR update page.

(4) The public can read/write to a wiki for my JSR.
The Jackrabbit wiki has been used by the community as a white board
of many jsr-283 related topics.

(5) I read and respond to posts on the discussion board for my JSR on
Well over one hundred substantive messages have been sent back and
forth through, these included inquiries and comments by the general
public that have been promptly answered.

(6) There is an issue-tracker for my JSR that the public can read.
Yes. For jsr-283 this has been and will be on the respective URL for the new JSR.

(7) I have spoken at conferences and events about my JSR recently.

(8) I am using open-source processes for the development of the RI and/or TCK.
Yes. The Apache Jackrabbit project hosts all the development of RI & TCK.

(9) The Update tab for my JSR has links to and information about all public communication mechanisms and sites for the development of my JSR.

2.16 Please describe how the RI and TCK will be 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.

Like it's predecessors JSR-170 and JSR-283 the specification, the API code, RI and TCK will be under an Apache-based license, thus providing the maximum in transparency and involving the community and the public to the maximum extent.

2.17 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).

Not Applicable.

2.18 Please provide the full text of the licenses that will apply to your Final Release Specification, Reference Implementation and Technology Compatibility Kit, or provide links to the same.

The RI and the TCK will be available under an Apache-based license, just as they are with JSR-170 and JSR-283.

Specification license

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.

Content Repository API for Java? Technology 1.0 (JSR-170):

Content Repository API for Java? Technology 2.0 (JSR-283):

Related Topics: Apache Jackrabbit Project:

JTA, Java Transaction API:

JMS, Java Message Service:

JCA, J2EE Connector Architecture:

Workspace Versioning and Configuration Management:

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

Version 2.0 of the specification (JSR-283) will be the basis of version 2.1 (this JSR).