[
https://issues.apache.org/jira/browse/JCR-853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting updated JCR-853:
------------------------------
Component/s: jackrabbit-core
Issue Type: Improvement (was: Bug)
Affects Version/s: (was: 1.2.1)
> [PATCH] Jackrabbit disallows some nodetype changes which are in fact safe.
> --------------------------------------------------------------------------
>
> Key: JCR-853
> URL: https://issues.apache.org/jira/browse/JCR-853
> Project: Jackrabbit
> Issue Type: Improvement
> Components: jackrabbit-core, nodetype
> Reporter: Simon Edwards
> Assignee: Stefan Guggisberg
> Priority: Minor
> Attachments: NodeTypeDefDiff_JCR-853.diff
>
>
> When reregistering nodetypes using
> org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.reregisterNodeType(),
> Jackrabbit uses the NodeTypeDefDiff class to compare the old nodetype
> definitions with the new definitions to determine if the nodetype changes can
> be permitted. Changing a node property from not multiple to multiple is safe
> and should be allowed, but there is a bug in NodeTypeDefDiff.java which
> prevents this change from being permitted.
> The NodeTypeDefDiff..buildPropDefDiffs() tries to compare the old and new
> version of each property definition. Around line 260, it tries to pull the
> new definition of a property out of a map using the PropDefId object from the
> old definition as a key. The problem is that this key is not only built up
> from the name of the property, but also from its attributes (e.g. multiple,
> type, constraints etc). This means that if the property definition changes,
> then the new property definition will have a different PropDefId than the old
> version and hence will not be found in the map. The code then treats the
> missing property definition as being a major change that can't be permitted.
> see patch.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
