You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Julian Reschke (JIRA)" <ji...@apache.org> on 2007/02/12 18:00:13 UTC
[jira] Created: (JCR-741) Handling of multiple residual prop defs
in EffectiveNodeTypeImpl
Handling of multiple residual prop defs in EffectiveNodeTypeImpl
----------------------------------------------------------------
Key: JCR-741
URL: https://issues.apache.org/jira/browse/JCR-741
Project: Jackrabbit
Issue Type: Bug
Components: SPI
Reporter: Julian Reschke
Priority: Minor
org.apache.jackrabbit.jcr2spi.nodetype.EffectiveNodeTypeImpl currently rejects multiple residual property definitions, if they do not differ in getMultiple(). In fact, it should accept all combinations, so differing values for getOnParentVersionAction and other aspects should be accepted as well.
See JSR 170, 6.7.8:
"For purposes of the above, the notion of two definitions having the same name does not apply to two residual definitions. Two (or more) residual property or child node definitions with differing subattributes must be permitted to co-exist in the same effective node type. They are interpreted as disjunctive (ORed) options."
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-741) Handling of multiple residual prop defs
in EffectiveNodeTypeImpl
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476110 ]
Marcel Reutegger commented on JCR-741:
--------------------------------------
I was thinking of a method that provides all the required information to resolve the ambiguous definitions. Something along the lines: 'hey, you gave me multiple matching property definitions when I wanted to create a property named 'foo', which one should I use?'
RepositoryService.resolvePropertyDefinition(SessionInfo sessionInfo, NodeInfo nodeInfo, QName propertyName, QPropertyDefinition[] definitions)
And similar for node definitions.
> Handling of multiple residual prop defs in EffectiveNodeTypeImpl
> ----------------------------------------------------------------
>
> Key: JCR-741
> URL: https://issues.apache.org/jira/browse/JCR-741
> Project: Jackrabbit
> Issue Type: Bug
> Components: SPI
> Reporter: Julian Reschke
> Assigned To: Julian Reschke
> Priority: Minor
>
> org.apache.jackrabbit.jcr2spi.nodetype.EffectiveNodeTypeImpl currently rejects multiple residual property definitions, if they do not differ in getMultiple(). In fact, it should accept all combinations, so differing values for getOnParentVersionAction and other aspects should be accepted as well.
> See JSR 170, 6.7.8:
> "For purposes of the above, the notion of two definitions having the same name does not apply to two residual definitions. Two (or more) residual property or child node definitions with differing subattributes must be permitted to co-exist in the same effective node type. They are interpreted as disjunctive (ORed) options."
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-741) Handling of multiple residual prop defs
in EffectiveNodeTypeImpl
Posted by "Julian Reschke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12474224 ]
Julian Reschke commented on JCR-741:
------------------------------------
Fixing this properly requires several changes.
(1) Do not consider multiple residual prop defs when they differ in their OnParentVersionAction value,
(2) Rewrite the transient layer so that in presence of multiple residuals it will pick the "right" one (such as for Property.getDefinition()).
As (1) is simple and allows my SPI stack to continue to work for now, I'll fix that right away.
For (2), I'd recommend to change getMatchingPropDef () as below:
- only one method
- each of the definition's aspects can be marked as "don't care" (by changing int->Integer, boolean->Boolean and allowing null values here).
Feedback appreciated.
> Handling of multiple residual prop defs in EffectiveNodeTypeImpl
> ----------------------------------------------------------------
>
> Key: JCR-741
> URL: https://issues.apache.org/jira/browse/JCR-741
> Project: Jackrabbit
> Issue Type: Bug
> Components: SPI
> Reporter: Julian Reschke
> Assigned To: Julian Reschke
> Priority: Minor
>
> org.apache.jackrabbit.jcr2spi.nodetype.EffectiveNodeTypeImpl currently rejects multiple residual property definitions, if they do not differ in getMultiple(). In fact, it should accept all combinations, so differing values for getOnParentVersionAction and other aspects should be accepted as well.
> See JSR 170, 6.7.8:
> "For purposes of the above, the notion of two definitions having the same name does not apply to two residual definitions. Two (or more) residual property or child node definitions with differing subattributes must be permitted to co-exist in the same effective node type. They are interpreted as disjunctive (ORed) options."
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-741) Handling of multiple residual prop defs
in EffectiveNodeTypeImpl
Posted by "Julian Reschke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478573 ]
Julian Reschke commented on JCR-741:
------------------------------------
OK, back to the drawing board.
It seems to me that EffectiveNodeTypeImpl is the wrong place, because it doesn't have access to the other ingredients, such as service, session, or propertyId.
Revised proposal: add EffectiveNodeType.getApplicablePropertyDefinitions()[], and let the caller (in this case WorkspaceItemStateFactory) sort things out.
Feedback appreciated.
> Handling of multiple residual prop defs in EffectiveNodeTypeImpl
> ----------------------------------------------------------------
>
> Key: JCR-741
> URL: https://issues.apache.org/jira/browse/JCR-741
> Project: Jackrabbit
> Issue Type: Bug
> Components: SPI
> Reporter: Julian Reschke
> Assigned To: Julian Reschke
> Priority: Minor
>
> org.apache.jackrabbit.jcr2spi.nodetype.EffectiveNodeTypeImpl currently rejects multiple residual property definitions, if they do not differ in getMultiple(). In fact, it should accept all combinations, so differing values for getOnParentVersionAction and other aspects should be accepted as well.
> See JSR 170, 6.7.8:
> "For purposes of the above, the notion of two definitions having the same name does not apply to two residual definitions. Two (or more) residual property or child node definitions with differing subattributes must be permitted to co-exist in the same effective node type. They are interpreted as disjunctive (ORed) options."
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-741) Handling of multiple residual prop defs
in EffectiveNodeTypeImpl
Posted by "Julian Reschke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475858 ]
Julian Reschke commented on JCR-741:
------------------------------------
- I do agree that we should avoid server round trips if the property definition is precisely known ahead of time.
- Not sure how you would do B). Can you be a bit more specific?
> Handling of multiple residual prop defs in EffectiveNodeTypeImpl
> ----------------------------------------------------------------
>
> Key: JCR-741
> URL: https://issues.apache.org/jira/browse/JCR-741
> Project: Jackrabbit
> Issue Type: Bug
> Components: SPI
> Reporter: Julian Reschke
> Assigned To: Julian Reschke
> Priority: Minor
>
> org.apache.jackrabbit.jcr2spi.nodetype.EffectiveNodeTypeImpl currently rejects multiple residual property definitions, if they do not differ in getMultiple(). In fact, it should accept all combinations, so differing values for getOnParentVersionAction and other aspects should be accepted as well.
> See JSR 170, 6.7.8:
> "For purposes of the above, the notion of two definitions having the same name does not apply to two residual definitions. Two (or more) residual property or child node definitions with differing subattributes must be permitted to co-exist in the same effective node type. They are interpreted as disjunctive (ORed) options."
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (JCR-741) Handling of multiple residual prop defs in
EffectiveNodeTypeImpl
Posted by "Julian Reschke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julian Reschke closed JCR-741.
------------------------------
Resolution: Fixed
Closing issue for now; test cases pass for my JCR2SPI based custom implementation.
> Handling of multiple residual prop defs in EffectiveNodeTypeImpl
> ----------------------------------------------------------------
>
> Key: JCR-741
> URL: https://issues.apache.org/jira/browse/JCR-741
> Project: Jackrabbit
> Issue Type: Bug
> Components: SPI
> Reporter: Julian Reschke
> Assignee: Julian Reschke
> Priority: Minor
>
> org.apache.jackrabbit.jcr2spi.nodetype.EffectiveNodeTypeImpl currently rejects multiple residual property definitions, if they do not differ in getMultiple(). In fact, it should accept all combinations, so differing values for getOnParentVersionAction and other aspects should be accepted as well.
> See JSR 170, 6.7.8:
> "For purposes of the above, the notion of two definitions having the same name does not apply to two residual definitions. Two (or more) residual property or child node definitions with differing subattributes must be permitted to co-exist in the same effective node type. They are interpreted as disjunctive (ORed) options."
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-741) Handling of multiple residual prop defs
in EffectiveNodeTypeImpl
Posted by "Julian Reschke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478798 ]
Julian Reschke commented on JCR-741:
------------------------------------
OK, I've added the most simple thing that will work for my case in Revision r515598. With this change, WorkspaceItemStateFactory will ask the SPI impl whenever there are multiple property definitions (this may cause an additional request in some edge cases compared to the previous approach).
> Handling of multiple residual prop defs in EffectiveNodeTypeImpl
> ----------------------------------------------------------------
>
> Key: JCR-741
> URL: https://issues.apache.org/jira/browse/JCR-741
> Project: Jackrabbit
> Issue Type: Bug
> Components: SPI
> Reporter: Julian Reschke
> Assigned To: Julian Reschke
> Priority: Minor
>
> org.apache.jackrabbit.jcr2spi.nodetype.EffectiveNodeTypeImpl currently rejects multiple residual property definitions, if they do not differ in getMultiple(). In fact, it should accept all combinations, so differing values for getOnParentVersionAction and other aspects should be accepted as well.
> See JSR 170, 6.7.8:
> "For purposes of the above, the notion of two definitions having the same name does not apply to two residual definitions. Two (or more) residual property or child node definitions with differing subattributes must be permitted to co-exist in the same effective node type. They are interpreted as disjunctive (ORed) options."
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-741) Handling of multiple residual prop defs
in EffectiveNodeTypeImpl
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478345 ]
Marcel Reutegger commented on JCR-741:
--------------------------------------
Hmm, if you have to do the call to the store anyway then I propose the following:
- Keep the methods RepositoryService.getPropertyDefinition() and RepositoryService.getNodeDefinition()
- Resolve the item definitions using the node type information whenever possible.
- If there is a conflicting situation with multiple residual definitions that match, ask the repository service for the correct one using RepositoryService.getPropertyDefinition() or RepositoryService.getNodeDefinition()
Does that work for you? Is there enough information in the parameters to decide which definition to use? Please also note that those calls will use ids that reference items that do not yet exist.
> Handling of multiple residual prop defs in EffectiveNodeTypeImpl
> ----------------------------------------------------------------
>
> Key: JCR-741
> URL: https://issues.apache.org/jira/browse/JCR-741
> Project: Jackrabbit
> Issue Type: Bug
> Components: SPI
> Reporter: Julian Reschke
> Assigned To: Julian Reschke
> Priority: Minor
>
> org.apache.jackrabbit.jcr2spi.nodetype.EffectiveNodeTypeImpl currently rejects multiple residual property definitions, if they do not differ in getMultiple(). In fact, it should accept all combinations, so differing values for getOnParentVersionAction and other aspects should be accepted as well.
> See JSR 170, 6.7.8:
> "For purposes of the above, the notion of two definitions having the same name does not apply to two residual definitions. Two (or more) residual property or child node definitions with differing subattributes must be permitted to co-exist in the same effective node type. They are interpreted as disjunctive (ORed) options."
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-741) Handling of multiple residual prop defs
in EffectiveNodeTypeImpl
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12477963 ]
Marcel Reutegger commented on JCR-741:
--------------------------------------
> Not convinced. If the node type allows multiple property definitions here, obtaining the right one from the
> store doesn't seem to be any harder than selecting one of the ones supplied by the caller.
my point is to possibly avoid a call (by an spi implementation) to the store and give an spi implementation the opportunity to implement the method as an entirely local call. Would this work in your case, or would you still have to ask the store to pick the right definition?
> Anyway; if we do that, do we still need RepositoryService.getPropertyDefinition? Right now it's not used
> by JCR2SPI which makes me a bit nervous :-).
IMO we should remove the method RepositoryService.getPropertyDefinition() anyway. It does not scale well and in almost all cases it can be infered from the node type definition which property definition applies to a certain property. I think the same also applies to child node definitions (jcr2spi only uses the method to get the node definition for the root node).
Using the node type definition and its item definitions require much lesser calls to the SPI than using getPropertyDefinition() and getNodeDefinition(). So, I think jcr2spi does it the right way, even though it doesn't use getPropertyDefinition().
> Handling of multiple residual prop defs in EffectiveNodeTypeImpl
> ----------------------------------------------------------------
>
> Key: JCR-741
> URL: https://issues.apache.org/jira/browse/JCR-741
> Project: Jackrabbit
> Issue Type: Bug
> Components: SPI
> Reporter: Julian Reschke
> Assigned To: Julian Reschke
> Priority: Minor
>
> org.apache.jackrabbit.jcr2spi.nodetype.EffectiveNodeTypeImpl currently rejects multiple residual property definitions, if they do not differ in getMultiple(). In fact, it should accept all combinations, so differing values for getOnParentVersionAction and other aspects should be accepted as well.
> See JSR 170, 6.7.8:
> "For purposes of the above, the notion of two definitions having the same name does not apply to two residual definitions. Two (or more) residual property or child node definitions with differing subattributes must be permitted to co-exist in the same effective node type. They are interpreted as disjunctive (ORed) options."
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-741) Handling of multiple residual prop defs
in EffectiveNodeTypeImpl
Posted by "Julian Reschke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476925 ]
Julian Reschke commented on JCR-741:
------------------------------------
Not convinced. If the node type allows multiple property definitions here, obtaining the right one from the store doesn't seem to be any harder than selecting one of the ones supplied by the caller. But maybe I'm missing something here.
Anyway; if we do that (as proposed in <https://issues.apache.org/jira/browse/JCR-741#action_12476110>), do we still need RepositoryService.getPropertyDefinition? Right now it's not used by JCR2SPI which makes me a bit nervous :-).
> Handling of multiple residual prop defs in EffectiveNodeTypeImpl
> ----------------------------------------------------------------
>
> Key: JCR-741
> URL: https://issues.apache.org/jira/browse/JCR-741
> Project: Jackrabbit
> Issue Type: Bug
> Components: SPI
> Reporter: Julian Reschke
> Assigned To: Julian Reschke
> Priority: Minor
>
> org.apache.jackrabbit.jcr2spi.nodetype.EffectiveNodeTypeImpl currently rejects multiple residual property definitions, if they do not differ in getMultiple(). In fact, it should accept all combinations, so differing values for getOnParentVersionAction and other aspects should be accepted as well.
> See JSR 170, 6.7.8:
> "For purposes of the above, the notion of two definitions having the same name does not apply to two residual definitions. Two (or more) residual property or child node definitions with differing subattributes must be permitted to co-exist in the same effective node type. They are interpreted as disjunctive (ORed) options."
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-741) Handling of multiple residual prop defs
in EffectiveNodeTypeImpl
Posted by "Julian Reschke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478423 ]
Julian Reschke commented on JCR-741:
------------------------------------
I think this will work for me; I'll try to adapt EffectiveNodeTypeImpl accordingly.
The fact that getPropertyDefinition() and getNodeDefinition() need to work on not-yet existing items probably should be added to the Javadoc, it may not be obvious to everybody...
> Handling of multiple residual prop defs in EffectiveNodeTypeImpl
> ----------------------------------------------------------------
>
> Key: JCR-741
> URL: https://issues.apache.org/jira/browse/JCR-741
> Project: Jackrabbit
> Issue Type: Bug
> Components: SPI
> Reporter: Julian Reschke
> Assigned To: Julian Reschke
> Priority: Minor
>
> org.apache.jackrabbit.jcr2spi.nodetype.EffectiveNodeTypeImpl currently rejects multiple residual property definitions, if they do not differ in getMultiple(). In fact, it should accept all combinations, so differing values for getOnParentVersionAction and other aspects should be accepted as well.
> See JSR 170, 6.7.8:
> "For purposes of the above, the notion of two definitions having the same name does not apply to two residual definitions. Two (or more) residual property or child node definitions with differing subattributes must be permitted to co-exist in the same effective node type. They are interpreted as disjunctive (ORed) options."
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-741) Handling of multiple residual prop defs
in EffectiveNodeTypeImpl
Posted by "Julian Reschke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478035 ]
Julian Reschke commented on JCR-741:
------------------------------------
> my point is to possibly avoid a call (by an spi implementation) to the store and give an spi implementation the opportunity to implement the method as an entirely local call. Would this work in your case, or would you still have to ask the store to pick the right definition?
In my case it wouldn't make a difference; only the store knows the right answer.
> IMO we should remove the method RepositoryService.getPropertyDefinition() anyway. It does not scale well and in almost all cases it can be infered from the node type definition which property definition applies to a certain property. I think the same also applies to child node definitions (jcr2spi only uses the method to get the node definition for the root node).
+1 on removing stuff from the API that isn't used by JCR2SPI.
> Using the node type definition and its item definitions require much lesser calls to the SPI than using getPropertyDefinition() and getNodeDefinition(). So, I think jcr2spi does it the right way, even though it doesn't use getPropertyDefinition().
Avoiding round-trips is good; we just need to make the special cases work. So what's the next step? Add resolvePropertyDefinition() as proposed?
> Handling of multiple residual prop defs in EffectiveNodeTypeImpl
> ----------------------------------------------------------------
>
> Key: JCR-741
> URL: https://issues.apache.org/jira/browse/JCR-741
> Project: Jackrabbit
> Issue Type: Bug
> Components: SPI
> Reporter: Julian Reschke
> Assigned To: Julian Reschke
> Priority: Minor
>
> org.apache.jackrabbit.jcr2spi.nodetype.EffectiveNodeTypeImpl currently rejects multiple residual property definitions, if they do not differ in getMultiple(). In fact, it should accept all combinations, so differing values for getOnParentVersionAction and other aspects should be accepted as well.
> See JSR 170, 6.7.8:
> "For purposes of the above, the notion of two definitions having the same name does not apply to two residual definitions. Two (or more) residual property or child node definitions with differing subattributes must be permitted to co-exist in the same effective node type. They are interpreted as disjunctive (ORed) options."
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-741) Handling of multiple residual prop defs
in EffectiveNodeTypeImpl
Posted by "Julian Reschke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476122 ]
Julian Reschke commented on JCR-741:
------------------------------------
That would work, but why would the SPI implementation would ever need the definitions parameter? For an existing property, an SPI implementation should always precisely know the QPropDef right?
Or is this about requesting the definition of a property *before* it is being created? That would be useful, but again I don't see what the definitions parameters would do here?
> Handling of multiple residual prop defs in EffectiveNodeTypeImpl
> ----------------------------------------------------------------
>
> Key: JCR-741
> URL: https://issues.apache.org/jira/browse/JCR-741
> Project: Jackrabbit
> Issue Type: Bug
> Components: SPI
> Reporter: Julian Reschke
> Assigned To: Julian Reschke
> Priority: Minor
>
> org.apache.jackrabbit.jcr2spi.nodetype.EffectiveNodeTypeImpl currently rejects multiple residual property definitions, if they do not differ in getMultiple(). In fact, it should accept all combinations, so differing values for getOnParentVersionAction and other aspects should be accepted as well.
> See JSR 170, 6.7.8:
> "For purposes of the above, the notion of two definitions having the same name does not apply to two residual definitions. Two (or more) residual property or child node definitions with differing subattributes must be permitted to co-exist in the same effective node type. They are interpreted as disjunctive (ORed) options."
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-741) Handling of multiple residual prop defs
in EffectiveNodeTypeImpl
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476578 ]
Marcel Reutegger commented on JCR-741:
--------------------------------------
The definitions are passed to avoid a potential server call-back. The SPI implementation may not have the property definitions at hand when just the node info and the property name is passed.
> Handling of multiple residual prop defs in EffectiveNodeTypeImpl
> ----------------------------------------------------------------
>
> Key: JCR-741
> URL: https://issues.apache.org/jira/browse/JCR-741
> Project: Jackrabbit
> Issue Type: Bug
> Components: SPI
> Reporter: Julian Reschke
> Assigned To: Julian Reschke
> Priority: Minor
>
> org.apache.jackrabbit.jcr2spi.nodetype.EffectiveNodeTypeImpl currently rejects multiple residual property definitions, if they do not differ in getMultiple(). In fact, it should accept all combinations, so differing values for getOnParentVersionAction and other aspects should be accepted as well.
> See JSR 170, 6.7.8:
> "For purposes of the above, the notion of two definitions having the same name does not apply to two residual definitions. Two (or more) residual property or child node definitions with differing subattributes must be permitted to co-exist in the same effective node type. They are interpreted as disjunctive (ORed) options."
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-741) Handling of multiple residual prop defs
in EffectiveNodeTypeImpl
Posted by "Julian Reschke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475647 ]
Julian Reschke commented on JCR-741:
------------------------------------
(1) Done earlier.
(2) I just spent more time on this, and the key problem seems to be that JCR2SPI does not use RepositoryService.getPropertyDefinition() at all. Changing WorkspaceItemStateFactory.createPropertyState(...) so that the property definition is always fetched from the repository service fixes the problem, because it avoids having to ask the EffectiveNodeType at all. Now this is probably a problem performance-wise -- wouldn't it make sense to add getDefinition to ItemInfo on SPI, so the additional roundtrip is not necessary?
> Handling of multiple residual prop defs in EffectiveNodeTypeImpl
> ----------------------------------------------------------------
>
> Key: JCR-741
> URL: https://issues.apache.org/jira/browse/JCR-741
> Project: Jackrabbit
> Issue Type: Bug
> Components: SPI
> Reporter: Julian Reschke
> Assigned To: Julian Reschke
> Priority: Minor
>
> org.apache.jackrabbit.jcr2spi.nodetype.EffectiveNodeTypeImpl currently rejects multiple residual property definitions, if they do not differ in getMultiple(). In fact, it should accept all combinations, so differing values for getOnParentVersionAction and other aspects should be accepted as well.
> See JSR 170, 6.7.8:
> "For purposes of the above, the notion of two definitions having the same name does not apply to two residual definitions. Two (or more) residual property or child node definitions with differing subattributes must be permitted to co-exist in the same effective node type. They are interpreted as disjunctive (ORed) options."
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JCR-741) Handling of multiple residual prop defs
in EffectiveNodeTypeImpl
Posted by "Julian Reschke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julian Reschke reassigned JCR-741:
----------------------------------
Assignee: Julian Reschke
> Handling of multiple residual prop defs in EffectiveNodeTypeImpl
> ----------------------------------------------------------------
>
> Key: JCR-741
> URL: https://issues.apache.org/jira/browse/JCR-741
> Project: Jackrabbit
> Issue Type: Bug
> Components: SPI
> Reporter: Julian Reschke
> Assigned To: Julian Reschke
> Priority: Minor
>
> org.apache.jackrabbit.jcr2spi.nodetype.EffectiveNodeTypeImpl currently rejects multiple residual property definitions, if they do not differ in getMultiple(). In fact, it should accept all combinations, so differing values for getOnParentVersionAction and other aspects should be accepted as well.
> See JSR 170, 6.7.8:
> "For purposes of the above, the notion of two definitions having the same name does not apply to two residual definitions. Two (or more) residual property or child node definitions with differing subattributes must be permitted to co-exist in the same effective node type. They are interpreted as disjunctive (ORed) options."
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-741) Handling of multiple residual prop defs
in EffectiveNodeTypeImpl
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475846 ]
Marcel Reutegger commented on JCR-741:
--------------------------------------
Hmm, this would move the responsibility to pick an item definition to the SPI implementation but at the same time also increase the complexity of the SPI implementation. ItemInfo can currently be implemented as a simple bean without the need for additional logic. Your suggestion would break this rule, but maybe it's worth it.
I see two other options:
A) JCR2SPI first tries to resolve the ItemDefinition based on the available node type information. E.g. the property jcr:primaryType is always well defined. If there is more than one matching residual definition present, JCR2SPI asks the repository service for a matching definition.
B) Change methods RepositoryService.get[Node|Property]Definition() in a way that they can be implemented without a need for a server roundtrip and then always use those methods to lookup an ItemDefinition.
Or even better implement both A & B?
Angela, what do you think?
> Handling of multiple residual prop defs in EffectiveNodeTypeImpl
> ----------------------------------------------------------------
>
> Key: JCR-741
> URL: https://issues.apache.org/jira/browse/JCR-741
> Project: Jackrabbit
> Issue Type: Bug
> Components: SPI
> Reporter: Julian Reschke
> Assigned To: Julian Reschke
> Priority: Minor
>
> org.apache.jackrabbit.jcr2spi.nodetype.EffectiveNodeTypeImpl currently rejects multiple residual property definitions, if they do not differ in getMultiple(). In fact, it should accept all combinations, so differing values for getOnParentVersionAction and other aspects should be accepted as well.
> See JSR 170, 6.7.8:
> "For purposes of the above, the notion of two definitions having the same name does not apply to two residual definitions. Two (or more) residual property or child node definitions with differing subattributes must be permitted to co-exist in the same effective node type. They are interpreted as disjunctive (ORed) options."
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.