You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Jukka Zitting (JIRA)" <ji...@apache.org> on 2006/03/07 00:34:02 UTC
[jira] Created: (JCR-333) NodeTypeDef depends on supertype ordering
NodeTypeDef depends on supertype ordering
-----------------------------------------
Key: JCR-333
URL: http://issues.apache.org/jira/browse/JCR-333
Project: Jackrabbit
Type: Bug
Components: nodetype
Versions: 0.9
Reporter: Jukka Zitting
Priority: Minor
Currently the NodeTypeDef.setSupertypes() method simply sets the given QName array as the supertype QName array of the defined node type, thus preserving whatever ordering a node type parser or ultimately a node type definition file uses. This causes problems for example in the equals() method that uses the order-sensitive Arrays.equals() method to check for equality of the supertype QName arrays. The current implementation does therefore not consider the node type definitions "A > B, C" and "A > C, B" as equal even though they really should be so considered.
The same problem affects also child node and property definitions. The proper fix for this issue would probably be to use Sets to store and handle this information.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (JCR-333) NodeTypeDef depends on supertype ordering
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-333?page=all ]
Jukka Zitting updated JCR-333:
------------------------------
Fix Version: 1.1
Version: 1.0
> NodeTypeDef depends on supertype ordering
> -----------------------------------------
>
> Key: JCR-333
> URL: http://issues.apache.org/jira/browse/JCR-333
> Project: Jackrabbit
> Type: Bug
> Components: nodetype
> Versions: 1.0, 0.9
> Reporter: Jukka Zitting
> Assignee: Stefan Guggisberg
> Priority: Minor
> Fix For: 1.1
>
> Currently the NodeTypeDef.setSupertypes() method simply sets the given QName array as the supertype QName array of the defined node type, thus preserving whatever ordering a node type parser or ultimately a node type definition file uses. This causes problems for example in the equals() method that uses the order-sensitive Arrays.equals() method to check for equality of the supertype QName arrays. The current implementation does therefore not consider the node type definitions "A > B, C" and "A > C, B" as equal even though they really should be so considered.
> The same problem affects also child node and property definitions. The proper fix for this issue would probably be to use Sets to store and handle this information.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Resolved: (JCR-333) NodeTypeDef depends on supertype
ordering
Posted by "Stefan Guggisberg (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-333?page=all ]
Stefan Guggisberg resolved JCR-333:
-----------------------------------
Resolution: Fixed
fixed as suggested (svn r384271)
> NodeTypeDef depends on supertype ordering
> -----------------------------------------
>
> Key: JCR-333
> URL: http://issues.apache.org/jira/browse/JCR-333
> Project: Jackrabbit
> Type: Bug
> Components: nodetype
> Versions: 0.9
> Reporter: Jukka Zitting
> Assignee: Stefan Guggisberg
> Priority: Minor
>
> Currently the NodeTypeDef.setSupertypes() method simply sets the given QName array as the supertype QName array of the defined node type, thus preserving whatever ordering a node type parser or ultimately a node type definition file uses. This causes problems for example in the equals() method that uses the order-sensitive Arrays.equals() method to check for equality of the supertype QName arrays. The current implementation does therefore not consider the node type definitions "A > B, C" and "A > C, B" as equal even though they really should be so considered.
> The same problem affects also child node and property definitions. The proper fix for this issue would probably be to use Sets to store and handle this information.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Assigned: (JCR-333) NodeTypeDef depends on supertype
ordering
Posted by "Stefan Guggisberg (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-333?page=all ]
Stefan Guggisberg reassigned JCR-333:
-------------------------------------
Assign To: Stefan Guggisberg
> NodeTypeDef depends on supertype ordering
> -----------------------------------------
>
> Key: JCR-333
> URL: http://issues.apache.org/jira/browse/JCR-333
> Project: Jackrabbit
> Type: Bug
> Components: nodetype
> Versions: 0.9
> Reporter: Jukka Zitting
> Assignee: Stefan Guggisberg
> Priority: Minor
>
> Currently the NodeTypeDef.setSupertypes() method simply sets the given QName array as the supertype QName array of the defined node type, thus preserving whatever ordering a node type parser or ultimately a node type definition file uses. This causes problems for example in the equals() method that uses the order-sensitive Arrays.equals() method to check for equality of the supertype QName arrays. The current implementation does therefore not consider the node type definitions "A > B, C" and "A > C, B" as equal even though they really should be so considered.
> The same problem affects also child node and property definitions. The proper fix for this issue would probably be to use Sets to store and handle this information.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira