[ https://jira.jboss.org/jira/browse/DNA-286?page=com.atlassian.jira.plugin... ] Randall Hauch updated DNA-286: ------------------------------ Component/s: API JCR Fix Version/s: 0.4 Affects Version/s: 0.3 Description: Our JCR implementation needs a namespace registry that stores the namespaces and their prefixes in such a way that they can be clustered. The best approach is probably to store the namespaces under "/jcr:system/" in a DNA-specific location (as the JCR spec does not specify that the namespaces are available as content. By doing this, the namespace registry would automatically work across a cluster (any clients that are using the same RepositorySource). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/DNA-286?page=com.atlassian.jira.plugin... ] Brian Carothers updated DNA-286: -------------------------------- Attachment: DNA-286.patch I believe that the JCR spec does allow the remapping of built-in namespaces. At least, that's the behavior that the Jackrabbit TCK explicitly tests. This patch removes the checks that prohibit mapping new prefixes to the built-in URIs. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/DNA-286?page=com.atlassian.jira.plugin... ] Randall Hauch commented on DNA-286: ----------------------------------- Thanks for catching this, Brian. However, I think we are both right, which means that the namespace management aspects of JCR are more complicated. Section 7.2.1 specifies the behavior for the workspace-level namespace registry, and specifically says "Attempting to re-assign a built-in prefix (jcr, nt, mix, xml or the empty prefix) to a new URI will throw a NamespaceException." Also, "Attempting to register a namespace with a prefix that begins with the characters 'xml' (in any combination of case) will throw a NamespaceException." So I believe the JcrWorkspace and JcrNamespaceRegistry code as originally committed is in fact compatible with this aspect. However, according to the JSR-170 specification, Section 6.3 defines the Session-level (local) namespace mapping behavior to be slightly different. Firstly, the URI supplied to the session-level methods must already be registered globally (in other words, the session methods only change the prefix of a globally-registered URI). Secondly, the session-level methods DO allow remapping any of the built-in namespaces to different prefixes (except for the default namespace URI). Thirdly, the new prefix may not begin with the characters 'xml' (in any combination of case). Fourthly, the default prefix (an empty string) may not be used as a new prefix. Fifthly, there are some subtleties regarding remapping of existing URIs to prefixes that are already used in a mapping (for more, see section 6.3.3 of JSR-170). Interestingly, the draft JSR-283 specification (Section 4.3.3) seems to have language that makes the session-level namespace mappings more usable. It specifically states that when a session is acquired, the workspace-level namespace mappings are copied into the session (though Section 5.3.1 states that workspace-level changes are immediately reflected in all Sessions, unless they are overridden in those Sessions, making it seem like the Sessions do not actually get a true "copy"). It also seems to relax the restrictions on mapping URIs that already are mapping, and addresses the cases when mappings are removed but are still needed (they are re-added, but using a different generated prefix so as to not clash with any workspace-level generated prefixes). The draft JSR-283 specification seems to no longer require that the URI in the session-level mappings must already exist in the global mappings. Suffice to say that the Session-level namespace management needs a little work. We'll have to identify whether JSR-283 is indeed relaxing any behavior of JSR-170, and if so, whether those changes are better. (Generally, I'd say we want to implement JSR-170, but the wording of JSR-170 in this case seems to have some major issues by only working with existing URIs.) Hopefully the specs are not in conflict. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/DNA-286?page=com.atlassian.jira.plugin... ] Randall Hauch resolved DNA-286. ------------------------------- Resolution: Done This change corrects the behavior of the Session's namespace-related methods, which are not the same as those in the NamespaceRegistry implementation associated with the workspace. This also corrected several of the TCK tests associated with namespaces. Note that the StringValueFactory in 'dna-graph' was changed to use a DNA namespace registry to convert a Name and Path to a string using the namespace prefixes. (This change affected a number of unit tests.) The result is that any Name and Path property values are treated correctly and properly converted to a string using the current namespace prefixes in the namespace registry. However, the BinaryValueFactory implementations should not use this StringValueFactory, since they need to convert values using the non-prefixed form (that is, the namespace URI). In the case of our JCR implementation, the above change to the Graph factories means that property values are properly mapped to strings using the Session's local mappings (which fall back on the Workspace's mappings). This corrected at least one TCK test. I believe this addresses all the concerns documented above. Therefore, marking as resolved. But as always, if this is not true, please reopen. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira