24 Repository Compliance

A JCR implementation must support the basic repository features:

Repository acquisition and user authentication and authorization (see §4 Connecting)
Reading through path, identifier and browse access (see §5 Reading)
Query (see §6 Query)
Export (see §7 Export)
Node Type Discovery (see §8 Node Type Discovery)
Permission and capability checking (see §9 Permissions and Capabilities)

These features must be supported by all JCR repositories.

In addition, a repository may support any subset of the additional features defined in sections §10 to §23.

The presence of each additional feature is individually testable either through querying the value of a repository descriptor (see §24.2 Repository Descriptors) or testing for the availability of a specific node type (see §24.3 Node Type-Related Features), thus allowing an application to programmatically determine the capabilities of a specific JCR implementation.

An implementation that supports all the additional features defined in this specification is a fully-compliant repository.

24.1 Definition of Support

By indicating support for testable feature, a repository asserts that it fully conforms to the semantics of that feature as defined in this specification, with two possible exceptions:

aspects of the feature clearly indicated as being optional (i.e., should, may, should not), and
aspects of the feature testable by their own repository descriptors (for example, whether a repository supports joins is separately testable from whether it supports searches in general).

However, to indicate that it supports a testable feature, a repository is only required to support that feature in some, not all, contexts. For example, a repository may restrict its support for a feature based on access control, path, or other criteria.

24.2 Repository Descriptors

Repository descriptors are used to test support for repository features that have a behavioral (as opposed to a data-model) aspect.

Each descriptor is identified by a unique key, which is a string. An implementation must recognize all the standard keys defined in this specification and may recognize additional implementation-specific keys. The full set of valid keys (both standard and implementation-specific) for an implementation is returned by

String[] Repository.getDescriptorKeys().

The method

boolean Repository.isStandardDescriptor(String key)

returns true if key is the name of a standard descriptor defined within this specification and false if it is either a valid implementation-specific key or not a valid key.

The method

boolean Repository.isSingleValueDescriptor(String key)

returns true if key is the name of a single value descriptor and false otherwise.

The value of a particular descriptor is found by passing that descriptor's key to either

Value Repository.getDescriptorValue(String key)

Value[] Repository.getDescriptorValues(String key).

depending on whether that key is defined to return a single or a multiple value.

The JCR 1.0 method

String Repository.getDescriptor()

is still supported as a convenience method. The call

String s = repository.getDescriptor(key);

is equivalent to

Value v = repository.getDescriptorValue(key);
String s = (v == null) ? null : v.getString();

24.2.1 Repository Information

Key	Descriptor
SPEC_VERSION_DESC	STRING: The version of the specification that this repository implements. For JCR 2.0 the value of this descriptor is “2.0”.
SPEC_NAME_DESC	STRING: The name of the specification that this repository implements. For JCR 2.0 the value of this descriptor is “Content Repository for Java Technology API”.
REP_VENDOR_DESC	STRING: The name of the repository vendor.
REP_VENDOR_URL_DESC	STRING: The URL of the repository vendor.
REP_NAME_DESC	STRING: The name of this repository implementation.
REP_VERSION_DESC	STRING: The version of this repository implementation.

24.2.2 General

Key	Descriptor
WRITE_SUPPORTED	BOOLEAN: Returns true if and only if repository content can be updated through the JCR API , as opposed to having read-only access (see §10 Writing).
IDENTIFIER_STABILITY	STRING: Returns one of the following javax.jcr.Repository constants indicating the stability of non-referenceable identifiers: IDENTIFIER_STABILITY_METHOD_DURATION: Identifiers may change between method calls IDENTIFIER_STABILITY_SAVE_DURATION: Identifiers are guaranteed stable within a single save/refresh cycle. IDENTIFIER_STABILITY_SESSION_DURATION: Identifiers are guaranteed stable within a single session. IDENTIFIER_STABILITY_INDEFINITE_DURATION: Identifiers are guaranteed to be stable forever. Note that referenceable identifiers always have this level of stability. See 3.7 Identifiers and §3.8 Referenceable Nodes.
OPTION_XML_IMPORT_SUPPORTED	BOOLEAN: Returns true if and only if XML import is supported (see §11 Import).
OPTION_UNFILED_CONTENT_SUPPORTED	BOOLEAN: Returns true if and only if unfiled content is supported (see §3.12 Unfiled Content).
OPTION_SIMPLE_VERSIONING_ SUPPORTED	BOOLEAN: Returns true if and only if simple versioning is supported (see §3.13 Versioning Model and §15 Versioning).
OPTION_ACTIVITIES_SUPPORTED	BOOLEAN: Returns true if and only if activities are supported (see §15.12 Activities).
OPTION_BASELINES_SUPPORTED	BOOLEAN: Returns true if and only if configurations and baselines are supported (see §3.13 Versioning Model and §15.13 Configurations and Baselines).
OPTION_ACCESS_CONTROL_SUPPORTED	BOOLEAN: Returns true if and only if access control is supported (see §16 Access Control Management).
OPTION_LOCKING_SUPPORTED	BOOLEAN: Returns true if and only if locking is supported (see §17 Locking).
OPTION_OBSERVATION_SUPPORTED	BOOLEAN: Returns true if and only if asynchronous observation is supported (see §12 Observation).
OPTION_JOURNALED_OBSERVATION_ SUPPORTED	BOOLEAN: Returns true if and only if journaled observation is supported (see §12 Observation).
OPTION_RETENTION_SUPPORTED	BOOLEAN: Returns true if and only if retention and hold are supported (see §20 Retention and Hold).
OPTION_LIFECYCLE_SUPPORTED	BOOLEAN: Returns true if and only if lifecycle management is supported (see §18 Lifecycle Management).
OPTION_TRANSACTIONS_SUPPORTED	BOOLEAN: Returns true if and only if transactions are supported (see §21 Transactions).
OPTION_WORKSPACE_MANAGEMENT_ SUPPORTED	BOOLEAN: Returns true if and only if workspace management is supported (see §13 Workspace Management).
OPTION_NODE_AND_PROPERTY_WITH_SAME_NAME_SUPPORTED	BOOLEAN: Returns true if and only if node and property with same name is supported (see §5.1.8 Node and Property with Same Name).

24.2.3 Node Operations

Key	Descriptor
OPTION_UPDATE_PRIMARY_NODE_TYPE_ SUPPORTED	BOOLEAN: Returns true if and only if the primary node type of an existing node can be updated (see §10.10.2 Updating a Node's Primary Type).
OPTION_UPDATE_MIXIN_NODE_TYPES_ SUPPORTED	BOOLEAN: Returns true if and only if the mixin node types of an existing node can be added and removed (see §10.10.3 Assigning Mixin Node Types).
OPTION_SHAREABLE_NODES_SUPPORTED	BOOLEAN: Returns true if and only if the creation of shareable nodes is supported (see §3.9 Shareable Nodes Model and §14 Shareable Nodes).

24.2.4 Node Type Management

These repository descriptors characterize the types of nodes an API consumer may register (see §19 Node Type Management). They do not constrain a repository's built-in node types (see §3.7 Node Types).

Key	Descriptor
OPTION_NODE_TYPE_MANAGEMENT_ SUPPORTED	BOOLEAN: Returns true if and only if node type management is supported.
NODE_TYPE_MANAGEMENT_INHERITANCE	STRING: Returns one of the following javax.jcr.Repository constants indicating the level of support for node type inheritance: NODE_TYPE_MANAGEMENT_INHERITANCE_MINIMAL: Registration of primary node types is limited to those which have only nt:base as supertype. Registration of mixin node types is limited to those without any supertypes. NODE_TYPE_MANAGEMENT_INHERITANCE_SINGLE: Registration of primary node types is limited to those with exactly one supertype. Registration of mixin node types is limited to those with at most one supertype. NODE_TYPE_MANAGEMENT_INHERITANCE_MULTIPLE: Primary node types can be registered with one or more supertypes. Mixin node types can be registered with zero or more supertypes.
NODE_TYPE_MANAGEMENT_OVERRIDES_ SUPPORTED	BOOLEAN: Returns true if and only if override of inherited property or child node definitions is supported (see §3.7.6 Node Type Inheritance).
NODE_TYPE_MANAGEMENT_PRIMARY_ITEM_ NAME_SUPPORTED	BOOLEAN: Returns true if and only if primary items are supported (see §3.7.1.7 Primary Item).
NODE_TYPE_MANAGEMENT_ORDERABLE_ CHILD_NODES_SUPPORTED	BOOLEAN: Returns true if and only if preservation of child node ordering is supported (see §5.2.2.1 Child Node Order Preservation).
NODE_TYPE_MANAGEMENT_RESIDUAL_ DEFINITIONS_SUPPORTED	BOOLEAN: Returns true if and only if residual property and child node definitions are supported (see §3.7.2.1.2 Item Definition Name and Residual Definitions).
NODE_TYPE_MANAGEMENT_AUTOCREATED_ DEFINITIONS_SUPPORTED	BOOLEAN: Returns true if and only if autocreated properties and child nodes are supported (see §3.7.2.3 Auto-Created).
NODE_TYPE_MANAGEMENT_SAME_NAME_ SIBLINGS_SUPPORTED	BOOLEAN: Returns true if and only if same-name sibling child nodes are supported (see §3.7.4.3 Same-Name Siblings).
NODE_TYPE_MANAGEMENT_PROPERTY_TYPES	LONG[]: Returns an array holding the javax.jcr.PropertyType constants for the property types (including UNDEFINED, if supported) that a registered node type can specify, or a zero-length array if registered node types cannot specify property definitions (see §3.6.1 Property Types).
NODE_TYPE_MANAGEMENT_MULTIVALUED_ PROPERTIES_SUPPORTED	boolean: Returns true if and only if multi-value properties are supported (see §3.6.3 Single and Multi-Value Properties).
NODE_TYPE_MANAGEMENT_MULTIPLE_ BINARY_PROPERTIES_SUPPORTED	BOOLEAN: Returns true if and only if registration of a node types with more than one BINARY property is permitted (see §3.6.1.7 BINARY).
NODE_TYPE_MANAGEMENT_VALUE_ CONSTRAINTS_SUPPORTED	BOOLEAN: Returns true if and only value-constraints are supported (see §3.7.3.6 Value Constraints).
NODE_TYPE_MANAGEMENT_UPDATE_IN_USE_SUPORTED	BOOLEAN: Returns true if and only the update of node types is supported for node types currently in use as the type of an existing node in the repository.

24.2.5 Query

Key	Descriptor
QUERY_LANGUAGES	STRING[]: Returns an array holding the constants representing the supported query languages, or a zero-sized array if query is not supported (see §6 Query).
QUERY_STORED_QUERIES_SUPPORTED	BOOLEAN: Returns true if and only if stored queries are supported (see §6.9.7 Stored Query).
QUERY_FULL_TEXT_SEARCH_SUPPORTED	BOOLEAN: Returns true if and only if full-text search is supported (see §6.7.19 FullTextSearch).
QUERY_JOINS	STRING: Returns one of the following javax.jcr.Repository constants indicating the level of support for joins in queries: QUERY_JOINS_NONE: Joins are not supported. Queries are limited to a single selector. QUERY_JOINS_INNER: Inner joins are supported. QUERY_JOINS_INNER_OUTER: Inner and outer joins are supported. See §6.7.5 Join.

24.2.6 Deprecated Descriptors

Key	Descriptor
LEVEL_1_SUPPORTED	BOOLEAN: Returns true if and only if OPTION_XML_EXPORT_SUPPORTED = true and QUERY_LANGUAGES is of non-zero length. These semantics are identical to those in JCR 1.0. This constant is deprecated.
LEVEL_2_SUPPORTED	BOOLEAN: Returns true if and only if LEVEL_1_SUPPORTED = true, WRITE_SUPPORTED = true and OPTION_XML_IMPORT_SUPPORTED = true. These semantics are identical to those in JCR 1.0. This constant is deprecated.
OPTION_QUERY_SQL_SUPPORTED	BOOLEAN: Returns true if and only if the (deprecated) JCR 1.0 SQL query language is supported . This constant is deprecated.
QUERY_XPATH_POS_INDEX	BOOLEAN: Returns false unless the (deprecated) JCR 1.0 XPath query language is supported. If JCR 1.0 XPath is supported then this descriptor has the same semantics as in JCR 1.0. This constant is deprecated.
QUERY_XPATH_DOC_ORDER	BOOLEAN: Returns false unless the (deprecated) JCR 1.0 XPath query language is supported. If JCR 1.0 XPath is supported then this descriptor has the same semantics as in JCR 1.0. This constant is deprecated.

24.2.7 Implementation-Specific Descriptors

Implementers are free to introduce their own descriptors. The descriptor keys should use Java package-style names in namespaces controlled by the implementer. The Repository.isStandardDescriptor method must return false for these keys.

24.3 Node Type-Related Features

The node type registry is used to test support for features which correspond to a JCR-defined node type. For example, support for referenceable nodes as a feature is equivalent to support for the node type mix:referenceable. Such features are more data model-oriented than the behavioral features reported by descriptors.

Testing for the availability of a particular node type is done using

boolean NodeTypeManager.hasNodeType(String nodeTypeName)

Any node types associated with a particular feature are described in the section describing that feature.

The presence of the indicated node types in the node type registry (tested with NodeTypeManager.hasNodeType, see §8.1 NodeTypeManager Object) indicates support for the corresponding feature.

Node Type	Feature
mix:referenceable	Referenceable nodes (see §3.8 Referenceable Nodes).
mix:created mix:mimeType mix:lastModified mix:title mix:language nt:hierarchyNode nt:file nt:linkedFile nt:folder nt:resource nt:address	Standard application node types, a repository can support a subset (see §3.7.11 Standard Application Node Types).
mix:etag	Entity tags (see §3.7.12 Entity Tags).
nt:unstructured	Unstructured content (see §3.7.13 Unstructured Content).
nt:nodeType nt:propertyDefinition nt:childNodeDefinition	Node type definition storage in content (see §3.7.14 Node Type Definition Storage).

24.4 Implementation Issues

JCR adapters built against some existing repositories may require a connection to the back-end repository to determine whether a feature is supported. Using methods on Repository (as opposed, for example, to methods on Session) to test support for a feature is therefore potentially problematic. However, several approaches are open to such adapters:

Establish a transient connection to the back-end (for example, using service-to-service authentication or as “guest”) to determine support for a feature.
Determine the features supported by the back-end upon application deployment, and store this in configuration file locally available to the JCR adapter at runtime.
Report the feature set supported by the type of back end, which may be a superset of the feature set supported by the specific instance of that back-end type.