jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Guggisberg (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (JCR-853) [PATCH] Jackrabbit disallows some nodetype changes which are in fact safe.
Date Tue, 19 Jun 2012 10:12:42 GMT

     [ https://issues.apache.org/jira/browse/JCR-853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Stefan Guggisberg resolved JCR-853.
-----------------------------------

    Resolution: Won't Fix

no progress in 4 years, resolving as "won't fix"
                
> [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 Content Repository
>          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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message