Created: (JCR-333) NodeTypeDef depends on supertype ordering

NodeTypeDef depends on supertype ordering
-----------------------------------------

         Key: JCR-333
         URL: http://i
ssues.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.atl
assian.com/software/jira

     [ 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://i
ssues.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.atl
assian.com/software/jira

     [ 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://i
ssues.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.atl
assian.com/software/jira

     [ 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://i
ssues.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.atl
assian.com/software/jira