JBoss DNA currently supports most of the Level 1 and Level 2 feature set defined by the JSR-170 specification. Queries, which are part of Level 1, are not implemented. Some of the L2 features such as workspace cloning and updating, corresponding nodes, and referential integrity for REFERENCE properties are also not yet implemented. As the current implementation does provide many of the features that may be needed by an application, we really hope that this release will allow you to give us some feedback on what we have so far.

JBoss DNA does not currently support any of the optional JCR features. Currently, the observation optional feature is planned to be complete prior to the 1.0 release. The locking optional feature may be implemented in this timeframe as well.

Although the JSR-170 specification requires implementation of the Session.checkPermission(String, String) method, it allows implementors to choose the granularity of their access controls. JBoss DNA supports coarse-grained, role-based access control at the repository and workspace level.

JBoss DNA currently defines two permissions: READONLY and READWRITE. If the Credentials passed into Session.login(...) (or the Subject from the AccessControlContext, if one of the no-credential login methods were used) has either role, the session will have the corresponding access to all workspaces within the repository. That is, having the READONLY role implies that Session.checkPermission(path, "read") will not throw an AccessDeniedException for any value of path in any workspace in the repository. Similarly, having the READWRITE role implies that Session.checkPermission(path, actions) will not throw an AccessDeniedException for any values of path and actions.

It is also possible to grant access only to one or more named workspaces. For a workspace named "staging", this can be done by assigning a role named READONLY.staging. Appending "." + workspaceName to the READWRITE role works as well.

As a final note, the JBoss DNA JCR implementation will likely have additional security roles added prior to the 1.0 release. A CONNECT role is already being used by the DNA REST Server to control whether users have access to the repository through that means.

JBoss DNA supports all of the built-in node types described in the JSR-170 specification. However, several of these node types (mix:lockable, mix:versionable, nt:version, nt:versionLabels, nt:versionHistory, and nt:frozenNode) are semantically meaningless as JBoss DNA does not yet support the locking or versioning optional features.

Although JBoss DNA does define some custom node types in the dna namespace, none of these node types are intended to be used by developers integrating with JBoss DNA and may be changed or removed at any time.

Although the JSR-170 specification does not require support for registration of custom types, JBoss DNA supports this extremely useful feature. Custom node types can be added at startup, as noted above or at runtime through a DNA-specific interface. JBoss DNA supports defining node types either through a JSR-283-like template approach or through the use of Compact Node Definition (CND) files. Both type registration mechanisms are supported equally within JBoss DNA, although the CND approach for defining node types is recommended.

Although the JSR-283 specification is not yet final, it does provide a useful means of programatically defining JCR node types. JBoss DNA supports a comparable node type definition API that implements the functionality from the specification, albeit with classes in an org.jboss.dna.jcr package. The intent is to deprecate these classes and replace their usage with the JSR-283 equivalents after JBoss DNA fully supports in the JSR-283 specification in a future release. Node types can be defined like so:

Session session = ... ;
NodeTypeManager nodeTypeManager = session.getWorkspace().getNodeTypeManager();

// Declare a mixin node type named "searchable" (with no namespace)
NodeTypeTemplate nodeType = nodeTypeManager.createNodeTypeTemplate();
nodeType.setName("searchable");
nodeType.setMixin(true);
nodeType.getNodeDefinitionTemplates().add(childNode);

// Add a mandatory child named "source" with a required primary type of "nt:file" 
NodeDefinitionTemplate childNode = nodeTypeManager.createNodeDefinitionTemplate();
childNode.setName("source");
childNode.setMandatory(true);
childNode.setRequiredPrimaryTypeNames(new String[] { "nt:file" });
childNode.setDefaultPrimaryType("nt:file");

// Add a multi-valued STRING property named "keywords"
PropertyDefinitionTemplate property = nodeTypeManager.createPropertyDefinitionTemplate();
property.setName("keywords");
property.setMultiple(true);
property.setRequiredType(PropertyType.STRING);
nodeType.getPropertyDefinitionTemplates().add(property);

// Register the custom node type
nodeTypeManager.registerNodeType(nodeType);

Residual properties and child node definitions can also be defined simply by not calling setName on the template.

Custom node types can be defined more succinctly through the Compact Node Definition file format. In fact, this is how JBoss DNA defines its built-in node types. An example CND file that declares the same node type as above would be:

[searchable] mixin
- keywords (string) multiple
+ source (nt:file) = nt:file

This definition could then be registered with the following code snippet.

String pathToCndFileInClassLoader = ...;
CndNodeTypeSource nodeTypeSource = new CndNodeTypeSource(pathToCndFileInClassLoader);

for (Problem problem : nodeTypeSource.getProblems()) {
    System.err.println(problem);
}
if (!nodeTypeSource.isValid()) {
    throw new IllegalStateException("Problems loading node types");
}

Session session = ... ;
NodeTypeManager nodeTypeManager = session.getWorkspace().getNodeTypeManager();
nodeTypeManager.registerNodeTypes(nodeTypeSource);