[JBoss JIRA] Created: (DNA-335) DNA's NodeTypeManager implementation does not allow multiple definitions with the same name
by Randall Hauch (JIRA)
DNA's NodeTypeManager implementation does not allow multiple definitions with the same name
-------------------------------------------------------------------------------------------
Key: DNA-335
URL: https://jira.jboss.org/jira/browse/DNA-335
Project: DNA
Issue Type: Bug
Reporter: Randall Hauch
The JCR Specification (version 1.0.1) does not preclude that there may be multiple property definitions with the same name, or that there may be multiple child definitions with the same name. JCR 1.0 (version 1.0.1) DOES say that there may be multiple residual definitions with the same name. However, the draft version of the JSR-283 specification does have a new section 4.7.15 that specifically addresses and allows multiple definitions with the same name, as long as they are distinguishable from the other definitions with the same name (for property definitions, this means the type must be different; for child node definitions, this means the required primary types attribute).
There are a number of places where the logic is expecting a single property definition (or child definition) given a node type and a definition name. This is obviously flawed. Also, our logic to select the "best" property definition or "best" child node definition doesn't seem to be correct, in that it tends to favor less-restricted definitions that are lower in the type hierarchy rather than very good matching definitions higher in the type hierarchy.
--
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
15 years, 1 month
[JBoss JIRA] Created: (DNA-101) potential user confusion between org.jboss.dna.spi.graph ValueFactory and ValueFormatException interfaces and similar javax.jcr interfaces
by Greg Haber (JIRA)
potential user confusion between org.jboss.dna.spi.graph ValueFactory and ValueFormatException interfaces and similar javax.jcr interfaces
------------------------------------------------------------------------------------------------------------------------------------------
Key: DNA-101
URL: http://jira.jboss.com/jira/browse/DNA-101
Project: DNA
Issue Type: Feature Request
Components: API
Affects Versions: 0.2
Reporter: Greg Haber
Priority: Trivial
The new org.jboss.dna.spi.graph.ValueFactory and package org.jboss.dna.spi.graph.ValueFormatException interfaces may be potentially confusing to users that are using both DNA and the underlying JCR APIs in the same code. This is because there are interfaces with exactly the same names, and with very similar purposes (the JCR interfaces deal with instances of the javax.jcr.Value class, where the DNA interfaces are for standard Java objects), in the javax.jcr package. We should think about changing the names of the DNA interfaces to avoid such potential confusion. This is a very minor issue, I would not object if we decided to leave the interface names unchanged.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 1 month
[JBoss JIRA] Created: (DNA-303) The workspace NamespaceRegistry implementation should be shared
by Randall Hauch (JIRA)
The workspace NamespaceRegistry implementation should be shared
---------------------------------------------------------------
Key: DNA-303
URL: https://jira.jboss.org/jira/browse/DNA-303
Project: DNA
Issue Type: Sub-task
Components: API, JCR
Affects Versions: 0.3
Reporter: Randall Hauch
Fix For: 0.4
The JcrWorkspace class currently uses the GraphNamespaceRegistry, which implements DNA's NamespaceRegistry implementation on top of namespace mappings stored in a graph. While this works for a single ExecutionContext, having a shared implementation for multiple JcrWorkspace objects means that the update methods need to be done with the ExecutionContext of the user making the changes. This would require changing the design a fair amount.
The NamespaceRegistry implementation would also need to be thread-safe.
--
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
15 years, 1 month
[JBoss JIRA] Created: (DNA-301) Most state managed within the Workspace should be shared among multiple Session instances
by Randall Hauch (JIRA)
Most state managed within the Workspace should be shared among multiple Session instances
-----------------------------------------------------------------------------------------
Key: DNA-301
URL: https://jira.jboss.org/jira/browse/DNA-301
Project: DNA
Issue Type: Task
Components: API, JCR
Affects Versions: 0.3
Reporter: Randall Hauch
Fix For: 0.4
Our current JcrWorkspace implementation is created to be used only by the one JcrSession instance associated with it. Currently, each Session would have it's own Workspace implementation, each of which would have its own copy of the namespace registry and node type manager.
However, one common use case for JCR involves creating many Session instances for the same workspace (e.g., this is the web app scenario). This means that we'd have a lot of Workspace instances (same number as Session instances) each with their own copy of the data. In fact, the node type manager should actually be "owned" (at least logically) by the repository, per section 6.7.9: "There is one node type registry per repository, therefore the NodeTypeManager is not workspace-specific; it provides introspection methods for the global, repository-wide set of available node types."
Therefore, a number of things that are currently in the JcrWorkspace implementation should be pulled out and reused for all JcrWorkspace instances created by the JcrRepository for the same logical workspace. This issue captures the set of tasks that are involved.
--
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
15 years, 1 month