A JCR implementationmust support thebasic repository features:
Repositoryacquisition and user authentication and authorization (see §4Connecting)
Reading throughpath, identifier and browse access (see §5Reading)
Query (see §6Query)
Export (see §7Export)
Node TypeDiscovery (see §8Node Type Discovery)
Permission andcapability checking (see §9Permissions and Capabilities)
These features must besupported by all JCR repositories.
In addition, arepositorymay support any subset of theadditionalfeatures defined in sections §10 to §23.
The presence of eachadditional feature is individually testable either through queryingthe value of a repository descriptor (see §24.2RepositoryDescriptors) or testing for the availability of a specific nodetype (see §24.3Node Type-Related Features), thus allowingan application to programmatically determine the capabilities of aspecific JCR implementation.
An implementation thatsupports all the additional features defined in this specificationis afully-compliant repository.
By indicating supportfor testable feature, a repository asserts that it fully conforms tothe semantics of that feature as defined in this specification, withtwo possible exceptions:
aspects of thefeature clearly indicated as being optional (i.e.,should,may,should not), and
aspects of thefeature testable by their own repository descriptors (for example,whether a repository supports joins is separately testable fromwhether it supports searches in general).
However, to indicatethat it supports a testable feature, a repository is only requiredto support that feature in some, not all, contexts. For example, arepository may restrict its support for a feature based on accesscontrol, path, or other criteria.
Repository descriptorsare used to test support for repository features that have abehavioral (as opposed to a data-model) aspect.
Each descriptor isidentified by a uniquekey, which is a string. Animplementation must recognize all the standard keys defined in thisspecification and may recognize additional implementation-specifickeys. The full set of valid keys (both standard andimplementation-specific) for an implementation is returned by
.
The method
returnsifis the name of a standard descriptor defined within thisspecification andif it is either a valid implementation-specific key or not a validkey.
The method
returnsifis the name of a single value descriptor andotherwise.
The value of aparticular descriptor is found by passing that descriptor's key toeither
or
.
depending on whetherthat key is defined to return a single or a multiple value.
The JCR 1.0 method
is still supported asa convenience method. The call
is equivalent to
These repositorydescriptors characterize the types of nodes an API consumer mayregister (see §19Node Type Management). They do notconstrain a repository's built-in node types (see §3.7NodeTypes).
). | |
Implementers are freeto introduce their own descriptors. The descriptor keys should useJava package-style names in namespaces controlled by theimplementer. Themethod must return false for these keys.
The node type registryis used to test support for features which correspond to aJCR-defined node type. For example, support forreferenceablenodes as a feature is equivalent to support for the node type.Such features are more data model-oriented than the behavioralfeatures reported by descriptors.
Testing for theavailability of a particular node type is done using
Any node typesassociated with a particular feature are described in the sectiondescribing that feature.
The presence of theindicated node types in the node type registry (tested with,see §8.1NodeTypeManager Object) indicates support for thecorresponding feature.
JCR adapters builtagainst some existing repositories may require a connection to theback-end repository to determine whether a feature is supported.Using methods on(as opposed, for example, to methods on)to test support for a feature is therefore potentially problematic.However, several approaches are open to such adapters:
Establish atransient connection to the back-end (for example, usingservice-to-service authentication or as “guest”) to determinesupport for a feature.
Determine thefeatures supported by the back-end upon application deployment, andstore this in configuration file locally available to the JCRadapter at runtime.
Report thefeature set supported by the type of back end, which may be asuperset of the feature set supported by the specific instance ofthat back-end type.