You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Tobias Bocanegra (JIRA)" <ji...@apache.org> on 2010/10/08 21:33:30 UTC
[jira] Created: (JCR-2772) replacing an extended mixin with it's
supertype is problematic
replacing an extended mixin with it's supertype is problematic
--------------------------------------------------------------
Key: JCR-2772
URL: https://issues.apache.org/jira/browse/JCR-2772
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: jackrabbit-core
Affects Versions: 2.0.0
Reporter: Tobias Bocanegra
node.addMixin() / node.removeMixin() have some checks to avoid redundant mixin settings on a node and not only when the node is saved.
eg: have 2 mixins: mix:A and mix:AA where mix:AA > mix:A and a node (N with mix:AA) on it.
then, N.addMixin(mix:A) has no effect, since it's regarded as redundant. so you have to remove mix:AA first and then add mix:A.
there is the first problem when applying mixin types programmatically, just be sure to remove them first before adding new ones.
the 2nd problem occurs when mix:A has a mandatory property. then somehow when downgrading from mix:AA to mix:A, some information is lost, and a save call results in
Unable to save node 'N': javax.jcr.nodetype.ConstraintViolationException: /test/A: mandatory property {}prop does not exist.
you need to "touch" the property, otherwise it will not work.
so only this works:
N.removeMixin("mix:AA");
N.addMixin("mix:A");
N.setProperty("prop", N.getProperty("prop").getValue());
session.save();
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-2772) replacing an extended mixin with it's
supertype is problematic
Posted by "Stefan Guggisberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefan Guggisberg resolved JCR-2772.
------------------------------------
Resolution: Fixed
Fix Version/s: 2.2.0
resolved as duplicate of JCR-2788
> replacing an extended mixin with it's supertype is problematic
> --------------------------------------------------------------
>
> Key: JCR-2772
> URL: https://issues.apache.org/jira/browse/JCR-2772
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-core
> Affects Versions: 2.0.0
> Reporter: Tobias Bocanegra
> Fix For: 2.2.0
>
>
> node.addMixin() / node.removeMixin() have some checks to avoid redundant mixin settings on a node and not only when the node is saved.
> eg: have 2 mixins: mix:A and mix:AA where mix:AA > mix:A and a node (N with mix:AA) on it.
> then, N.addMixin(mix:A) has no effect, since it's regarded as redundant. so you have to remove mix:AA first and then add mix:A.
> there is the first problem when applying mixin types programmatically, just be sure to remove them first before adding new ones.
> the 2nd problem occurs when mix:A has a mandatory property. then somehow when downgrading from mix:AA to mix:A, some information is lost, and a save call results in
> Unable to save node 'N': javax.jcr.nodetype.ConstraintViolationException: /test/A: mandatory property {}prop does not exist.
> you need to "touch" the property, otherwise it will not work.
> so only this works:
> N.removeMixin("mix:AA");
> N.addMixin("mix:A");
> N.setProperty("prop", N.getProperty("prop").getValue());
> session.save();
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-2772) replacing an extended mixin with it's
supertype is problematic
Posted by "Stefan Guggisberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12919878#action_12919878 ]
Stefan Guggisberg commented on JCR-2772:
----------------------------------------
> > checks to avoid redundant mixin
>
> is this mandated by the specification?
yes, see [1].
<quote>
If this node is already of type mixinName (either due to a previously added mixin or due to its primary type, through inheritance) then this method has no effect. Otherwise mixinName is added to this node's jcr:mixinTypes property.
</quote>
there's also a TCK test which expects the current behavior (adding a redundant mixin results in a nop).
[1] http://www.day.com/maven/jsr170/javadocs/jcr-2.0/javax/jcr/Node.html#addMixin(java.lang.String)
> replacing an extended mixin with it's supertype is problematic
> --------------------------------------------------------------
>
> Key: JCR-2772
> URL: https://issues.apache.org/jira/browse/JCR-2772
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-core
> Affects Versions: 2.0.0
> Reporter: Tobias Bocanegra
>
> node.addMixin() / node.removeMixin() have some checks to avoid redundant mixin settings on a node and not only when the node is saved.
> eg: have 2 mixins: mix:A and mix:AA where mix:AA > mix:A and a node (N with mix:AA) on it.
> then, N.addMixin(mix:A) has no effect, since it's regarded as redundant. so you have to remove mix:AA first and then add mix:A.
> there is the first problem when applying mixin types programmatically, just be sure to remove them first before adding new ones.
> the 2nd problem occurs when mix:A has a mandatory property. then somehow when downgrading from mix:AA to mix:A, some information is lost, and a save call results in
> Unable to save node 'N': javax.jcr.nodetype.ConstraintViolationException: /test/A: mandatory property {}prop does not exist.
> you need to "touch" the property, otherwise it will not work.
> so only this works:
> N.removeMixin("mix:AA");
> N.addMixin("mix:A");
> N.setProperty("prop", N.getProperty("prop").getValue());
> session.save();
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-2772) replacing an extended mixin with it's
supertype is problematic
Posted by "Tobias Bocanegra (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12919358#action_12919358 ]
Tobias Bocanegra commented on JCR-2772:
---------------------------------------
ideally, unneeded mixin types are not removed until the save call.
> replacing an extended mixin with it's supertype is problematic
> --------------------------------------------------------------
>
> Key: JCR-2772
> URL: https://issues.apache.org/jira/browse/JCR-2772
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
> Affects Versions: 2.0.0
> Reporter: Tobias Bocanegra
>
> node.addMixin() / node.removeMixin() have some checks to avoid redundant mixin settings on a node and not only when the node is saved.
> eg: have 2 mixins: mix:A and mix:AA where mix:AA > mix:A and a node (N with mix:AA) on it.
> then, N.addMixin(mix:A) has no effect, since it's regarded as redundant. so you have to remove mix:AA first and then add mix:A.
> there is the first problem when applying mixin types programmatically, just be sure to remove them first before adding new ones.
> the 2nd problem occurs when mix:A has a mandatory property. then somehow when downgrading from mix:AA to mix:A, some information is lost, and a save call results in
> Unable to save node 'N': javax.jcr.nodetype.ConstraintViolationException: /test/A: mandatory property {}prop does not exist.
> you need to "touch" the property, otherwise it will not work.
> so only this works:
> N.removeMixin("mix:AA");
> N.addMixin("mix:A");
> N.setProperty("prop", N.getProperty("prop").getValue());
> session.save();
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-2772) replacing an extended mixin with it's
supertype is problematic
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12919756#action_12919756 ]
Marcel Reutegger commented on JCR-2772:
---------------------------------------
> checks to avoid redundant mixin
is this mandated by the specification?
> replacing an extended mixin with it's supertype is problematic
> --------------------------------------------------------------
>
> Key: JCR-2772
> URL: https://issues.apache.org/jira/browse/JCR-2772
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
> Affects Versions: 2.0.0
> Reporter: Tobias Bocanegra
>
> node.addMixin() / node.removeMixin() have some checks to avoid redundant mixin settings on a node and not only when the node is saved.
> eg: have 2 mixins: mix:A and mix:AA where mix:AA > mix:A and a node (N with mix:AA) on it.
> then, N.addMixin(mix:A) has no effect, since it's regarded as redundant. so you have to remove mix:AA first and then add mix:A.
> there is the first problem when applying mixin types programmatically, just be sure to remove them first before adding new ones.
> the 2nd problem occurs when mix:A has a mandatory property. then somehow when downgrading from mix:AA to mix:A, some information is lost, and a save call results in
> Unable to save node 'N': javax.jcr.nodetype.ConstraintViolationException: /test/A: mandatory property {}prop does not exist.
> you need to "touch" the property, otherwise it will not work.
> so only this works:
> N.removeMixin("mix:AA");
> N.addMixin("mix:A");
> N.setProperty("prop", N.getProperty("prop").getValue());
> session.save();
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-2772) replacing an extended mixin with it's
supertype is problematic
Posted by "Stefan Guggisberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefan Guggisberg updated JCR-2772:
-----------------------------------
Issue Type: Improvement (was: Bug)
not a bug since the current behavior is according to the spec.
> replacing an extended mixin with it's supertype is problematic
> --------------------------------------------------------------
>
> Key: JCR-2772
> URL: https://issues.apache.org/jira/browse/JCR-2772
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-core
> Affects Versions: 2.0.0
> Reporter: Tobias Bocanegra
>
> node.addMixin() / node.removeMixin() have some checks to avoid redundant mixin settings on a node and not only when the node is saved.
> eg: have 2 mixins: mix:A and mix:AA where mix:AA > mix:A and a node (N with mix:AA) on it.
> then, N.addMixin(mix:A) has no effect, since it's regarded as redundant. so you have to remove mix:AA first and then add mix:A.
> there is the first problem when applying mixin types programmatically, just be sure to remove them first before adding new ones.
> the 2nd problem occurs when mix:A has a mandatory property. then somehow when downgrading from mix:AA to mix:A, some information is lost, and a save call results in
> Unable to save node 'N': javax.jcr.nodetype.ConstraintViolationException: /test/A: mandatory property {}prop does not exist.
> you need to "touch" the property, otherwise it will not work.
> so only this works:
> N.removeMixin("mix:AA");
> N.addMixin("mix:A");
> N.setProperty("prop", N.getProperty("prop").getValue());
> session.save();
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.