[ https://jira.jboss.org/jira/browse/DNA-392?page=com.atlassian.jira.plugin... ] Randall Hauch updated DNA-392: ------------------------------ Fix Version/s: 0.6 (was: 0.5) Moving to 0.6 so that 0.5 can be shorter and more narrowly focused. -- 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-392?page=com.atlassian.jira.plugin... ] Randall Hauch commented on DNA-392: ----------------------------------- The JCR implementation was changed so that the JcrRepository now uses an internal federated connector, with the "/jcr:system" branch being projected from an in-memory repository created and owned by the JcrRepository instance, and the remaining content being projected from the actual source being used by the JCR repository (which itself can be federated). The internal NamespaceRegistry and RepositoryNodeTypeManager both use the internal in-memory source to make changes, and the "/jcr:system => /jcr:system" projection is then read-only (meaning the content under "/jcr:system" cannot be changed via the JcrSession or JcrWorkspace). This design offers a couple of very nice features. First of all, the federated connector was designed to handle this specific configuration, which it calls a "mirror-branch", since the main content is a mirror projection that is very cheap since it requires no path adjustments, and there is a single branch (the "jcr:system" branch) that also requires no path adjustments. Secondly, this setup is managed by the JcrRepository instance and does not require any of the configured RepositorySource instances to be set up with a "jcr:system" branch. However, this means that all JcrSession and JcrWorkspace instances created by the JcrRepository instance all share the exact same "jcr:system" content. Third, the JcrSession and JcrWorkspace classes no longer do anything special with the "jcr:system" branch, making them much more lightweight. In fact, none of the other code was changed (other than removing code that explicitly dealt with the pseudo "jcr:system" branch that appeared in each workspace). These classes don't have to care where the "jcr:system" content comes from, since the content just is there. Interestingly, there doesn't appear to be much of a change in the times required to run the build. On my machine, the change in times are well within the noise. In fact, some builds with this change actually took less time to run all of the JCR unit tests than without this change. I would guess that the extra time require to do the federation work is simply offset by the reduction in time required to create a session. -- 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-392?page=com.atlassian.jira.plugin... ] Randall Hauch commented on DNA-392: ----------------------------------- Initial commit that changed to use the federated connector within a JcrRepository implementation, and that results in all JcrSession and JcrWorkspace instances created by that JcrRepository instance to have the exact same (projected) content for the 'jcr:system' branch. All tests do pass. -- 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-392?page=com.atlassian.jira.plugin... ] Randall Hauch commented on DNA-392: ----------------------------------- Changed the JcrRepository implementation to have a new option that defines the source name (and optionally workspace name) where the /jcr:system branch is to be found. If this option is not used, or if the supplied names do not correspond to a valid workspace in an existing source, a transient in-memory source will be used. The existing JcrConfiguration and JcrEngine are already able to process any options, so they do not need to be changed to allow a configuration to define the /jcr:system branch location. -- 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