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 2008/04/17 15:43:21 UTC
[jira] Created: (JCR-1543) Improve reliability of canAddMixin
Improve reliability of canAddMixin
----------------------------------
Key: JCR-1543
URL: https://issues.apache.org/jira/browse/JCR-1543
Project: Jackrabbit
Issue Type: Improvement
Components: jackrabbit-spi
Reporter: Julian Reschke
Assignee: Julian Reschke
Priority: Minor
The current implementation of canAddMixin in JCR2SPI lacks flexibility. It only consults the (SPI) node type registry, checking for (1) whether the mixin exists, and (2) whether it is already present and (3) whether it's consistent with the node's type.
This is fine for stores where any legal mixin can be added anywhere. It doesn't work well for stores that are limited in what they can do; for instance when nt:file nodes can be made mix:versionable, but nt:folder nodes can't.
Proposal: enhance QNodeTypeDefinition with
public Name[] getSupportedMixins();
where the return value is either null (no constraints or no constraints known), or a list of mixin types that are supported for this node type.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1543) Improve reliability of canAddMixin
Posted by "Julian Reschke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julian Reschke updated JCR-1543:
--------------------------------
Attachment: JCR1543.diff
New proposed patch.
> Improve reliability of canAddMixin
> ----------------------------------
>
> Key: JCR-1543
> URL: https://issues.apache.org/jira/browse/JCR-1543
> Project: Jackrabbit
> Issue Type: Improvement
> Components: jackrabbit-spi
> Reporter: Julian Reschke
> Assignee: Julian Reschke
> Priority: Minor
> Attachments: JCR1543.diff, JCR1543.diff
>
>
> The current implementation of canAddMixin in JCR2SPI lacks flexibility. It only consults the (SPI) node type registry, checking for (1) whether the mixin exists, and (2) whether it is already present and (3) whether it's consistent with the node's type.
> This is fine for stores where any legal mixin can be added anywhere. It doesn't work well for stores that are limited in what they can do; for instance when nt:file nodes can be made mix:versionable, but nt:folder nodes can't.
> Proposal: enhance QNodeTypeDefinition with
> public Name[] getSupportedMixins();
> where the return value is either null (no constraints or no constraints known), or a list of mixin types that are supported for this node type.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1543) Improve reliability of canAddMixin
Posted by "angela (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12590448#action_12590448 ]
angela commented on JCR-1543:
-----------------------------
> Naming of method: I wanted to avoid canAddMixin, as the method has different
> semantics compared to canAddMixin (it just checks one of many things).
ok. i see... fine by me.
> Improve reliability of canAddMixin
> ----------------------------------
>
> Key: JCR-1543
> URL: https://issues.apache.org/jira/browse/JCR-1543
> Project: Jackrabbit
> Issue Type: Improvement
> Components: jackrabbit-spi
> Reporter: Julian Reschke
> Assignee: Julian Reschke
> Priority: Minor
> Attachments: JCR1543.diff, JCR1543.diff, JCR1543.diff
>
>
> The current implementation of canAddMixin in JCR2SPI lacks flexibility. It only consults the (SPI) node type registry, checking for (1) whether the mixin exists, and (2) whether it is already present and (3) whether it's consistent with the node's type.
> This is fine for stores where any legal mixin can be added anywhere. It doesn't work well for stores that are limited in what they can do; for instance when nt:file nodes can be made mix:versionable, but nt:folder nodes can't.
> Proposal: enhance QNodeTypeDefinition with
> public Name[] getSupportedMixins();
> where the return value is either null (no constraints or no constraints known), or a list of mixin types that are supported for this node type.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1543) Improve reliability of canAddMixin
Posted by "Julian Reschke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12590389#action_12590389 ]
Julian Reschke commented on JCR-1543:
-------------------------------------
QNodeTypeDefinitionImpl: done
Naming of method: I wanted to avoid canAddMixin, as the method has different semantics compared to canAddMixin (it just checks one of many things).
> Improve reliability of canAddMixin
> ----------------------------------
>
> Key: JCR-1543
> URL: https://issues.apache.org/jira/browse/JCR-1543
> Project: Jackrabbit
> Issue Type: Improvement
> Components: jackrabbit-spi
> Reporter: Julian Reschke
> Assignee: Julian Reschke
> Priority: Minor
> Attachments: JCR1543.diff, JCR1543.diff
>
>
> The current implementation of canAddMixin in JCR2SPI lacks flexibility. It only consults the (SPI) node type registry, checking for (1) whether the mixin exists, and (2) whether it is already present and (3) whether it's consistent with the node's type.
> This is fine for stores where any legal mixin can be added anywhere. It doesn't work well for stores that are limited in what they can do; for instance when nt:file nodes can be made mix:versionable, but nt:folder nodes can't.
> Proposal: enhance QNodeTypeDefinition with
> public Name[] getSupportedMixins();
> where the return value is either null (no constraints or no constraints known), or a list of mixin types that are supported for this node type.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1543) Improve reliability of canAddMixin
Posted by "Julian Reschke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julian Reschke updated JCR-1543:
--------------------------------
Attachment: JCR1543.diff
Proposed patch (interface, use in JCR2SPI, dummy impl in spi-commons)
> Improve reliability of canAddMixin
> ----------------------------------
>
> Key: JCR-1543
> URL: https://issues.apache.org/jira/browse/JCR-1543
> Project: Jackrabbit
> Issue Type: Improvement
> Components: jackrabbit-spi
> Reporter: Julian Reschke
> Assignee: Julian Reschke
> Priority: Minor
> Attachments: JCR1543.diff
>
>
> The current implementation of canAddMixin in JCR2SPI lacks flexibility. It only consults the (SPI) node type registry, checking for (1) whether the mixin exists, and (2) whether it is already present and (3) whether it's consistent with the node's type.
> This is fine for stores where any legal mixin can be added anywhere. It doesn't work well for stores that are limited in what they can do; for instance when nt:file nodes can be made mix:versionable, but nt:folder nodes can't.
> Proposal: enhance QNodeTypeDefinition with
> public Name[] getSupportedMixins();
> where the return value is either null (no constraints or no constraints known), or a list of mixin types that are supported for this node type.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1543) Improve reliability of canAddMixin
Posted by "angela (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
angela updated JCR-1543:
------------------------
Fix Version/s: 1.5
Affects Version/s: 1.4
> Improve reliability of canAddMixin
> ----------------------------------
>
> Key: JCR-1543
> URL: https://issues.apache.org/jira/browse/JCR-1543
> Project: Jackrabbit
> Issue Type: Improvement
> Components: jackrabbit-spi
> Affects Versions: 1.4
> Reporter: Julian Reschke
> Assignee: Julian Reschke
> Priority: Minor
> Fix For: 1.5
>
> Attachments: JCR1543.diff, JCR1543.diff, JCR1543.diff
>
>
> The current implementation of canAddMixin in JCR2SPI lacks flexibility. It only consults the (SPI) node type registry, checking for (1) whether the mixin exists, and (2) whether it is already present and (3) whether it's consistent with the node's type.
> This is fine for stores where any legal mixin can be added anywhere. It doesn't work well for stores that are limited in what they can do; for instance when nt:file nodes can be made mix:versionable, but nt:folder nodes can't.
> Proposal: enhance QNodeTypeDefinition with
> public Name[] getSupportedMixins();
> where the return value is either null (no constraints or no constraints known), or a list of mixin types that are supported for this node type.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1543) Improve reliability of canAddMixin
Posted by "angela (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12590343#action_12590343 ]
angela commented on JCR-1543:
-----------------------------
sounds reasonable to me.
comments to the patch:
QNodeTypeDefinitionImpl:
- i think having an additional constructor for QNodeTypeDefinitionImpl including the
supported mixin types would be reasonable.
- the current available constructor would then pass 'null' and just forward the params.
i would prefer that over always returning null.
EffectiveNodeType:
- maybe i would prefer the new method to be name canAddMixin instead of supportsMixin... but
that's just the first idea. no strong feelings.
> Improve reliability of canAddMixin
> ----------------------------------
>
> Key: JCR-1543
> URL: https://issues.apache.org/jira/browse/JCR-1543
> Project: Jackrabbit
> Issue Type: Improvement
> Components: jackrabbit-spi
> Reporter: Julian Reschke
> Assignee: Julian Reschke
> Priority: Minor
> Attachments: JCR1543.diff
>
>
> The current implementation of canAddMixin in JCR2SPI lacks flexibility. It only consults the (SPI) node type registry, checking for (1) whether the mixin exists, and (2) whether it is already present and (3) whether it's consistent with the node's type.
> This is fine for stores where any legal mixin can be added anywhere. It doesn't work well for stores that are limited in what they can do; for instance when nt:file nodes can be made mix:versionable, but nt:folder nodes can't.
> Proposal: enhance QNodeTypeDefinition with
> public Name[] getSupportedMixins();
> where the return value is either null (no constraints or no constraints known), or a list of mixin types that are supported for this node type.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1543) Improve reliability of canAddMixin
Posted by "Julian Reschke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julian Reschke updated JCR-1543:
--------------------------------
Attachment: JCR1543.diff
New proposed patch (information wasn't duplicated in ENT.clone()).
> Improve reliability of canAddMixin
> ----------------------------------
>
> Key: JCR-1543
> URL: https://issues.apache.org/jira/browse/JCR-1543
> Project: Jackrabbit
> Issue Type: Improvement
> Components: jackrabbit-spi
> Reporter: Julian Reschke
> Assignee: Julian Reschke
> Priority: Minor
> Attachments: JCR1543.diff, JCR1543.diff, JCR1543.diff
>
>
> The current implementation of canAddMixin in JCR2SPI lacks flexibility. It only consults the (SPI) node type registry, checking for (1) whether the mixin exists, and (2) whether it is already present and (3) whether it's consistent with the node's type.
> This is fine for stores where any legal mixin can be added anywhere. It doesn't work well for stores that are limited in what they can do; for instance when nt:file nodes can be made mix:versionable, but nt:folder nodes can't.
> Proposal: enhance QNodeTypeDefinition with
> public Name[] getSupportedMixins();
> where the return value is either null (no constraints or no constraints known), or a list of mixin types that are supported for this node type.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1543) Improve reliability of canAddMixin
Posted by "angela (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12592407#action_12592407 ]
angela commented on JCR-1543:
-----------------------------
adjusted in sandbox/spi: rev. 651630
> Improve reliability of canAddMixin
> ----------------------------------
>
> Key: JCR-1543
> URL: https://issues.apache.org/jira/browse/JCR-1543
> Project: Jackrabbit
> Issue Type: Improvement
> Components: jackrabbit-spi
> Affects Versions: 1.4
> Reporter: Julian Reschke
> Assignee: Julian Reschke
> Priority: Minor
> Fix For: 1.5
>
> Attachments: JCR1543.diff, JCR1543.diff, JCR1543.diff
>
>
> The current implementation of canAddMixin in JCR2SPI lacks flexibility. It only consults the (SPI) node type registry, checking for (1) whether the mixin exists, and (2) whether it is already present and (3) whether it's consistent with the node's type.
> This is fine for stores where any legal mixin can be added anywhere. It doesn't work well for stores that are limited in what they can do; for instance when nt:file nodes can be made mix:versionable, but nt:folder nodes can't.
> Proposal: enhance QNodeTypeDefinition with
> public Name[] getSupportedMixins();
> where the return value is either null (no constraints or no constraints known), or a list of mixin types that are supported for this node type.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1543) Improve reliability of canAddMixin
Posted by "Julian Reschke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julian Reschke resolved JCR-1543.
---------------------------------
Resolution: Fixed
Implemented with revision 649548.
> Improve reliability of canAddMixin
> ----------------------------------
>
> Key: JCR-1543
> URL: https://issues.apache.org/jira/browse/JCR-1543
> Project: Jackrabbit
> Issue Type: Improvement
> Components: jackrabbit-spi
> Reporter: Julian Reschke
> Assignee: Julian Reschke
> Priority: Minor
> Attachments: JCR1543.diff, JCR1543.diff, JCR1543.diff
>
>
> The current implementation of canAddMixin in JCR2SPI lacks flexibility. It only consults the (SPI) node type registry, checking for (1) whether the mixin exists, and (2) whether it is already present and (3) whether it's consistent with the node's type.
> This is fine for stores where any legal mixin can be added anywhere. It doesn't work well for stores that are limited in what they can do; for instance when nt:file nodes can be made mix:versionable, but nt:folder nodes can't.
> Proposal: enhance QNodeTypeDefinition with
> public Name[] getSupportedMixins();
> where the return value is either null (no constraints or no constraints known), or a list of mixin types that are supported for this node type.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.