[jira] Created: (JCR-1632) Mixin type loss

Mixin type loss
---------------

                 Key: JCR-1632
                 URL: https://issues.apache.org/jira/browse/JCR-1632
             Project: Jackrabbit
          Issue Type: Bug
          Components: jackrabbit-core
    Affects Versions: 1.4
         Environment: Linux 64-Bit (openSUSE 10.3) using Java 1.5.0_12 64-Bit

            Reporter: Frederic Laugier
             Fix For: 1.5


When using a bundle persistence manager, the mixin type information may be corrupted in the lucene index, causing queries like '//element(*, my:mixin)' to fail.



The problem is that the 'jcr:mixinTypes' may be stored in the bundle. Here is how this could happen :


First step: Create a node and add a mixin 'A'.

Everything's fine. The query '//element(*, 'A')' works.


Second step : Select the node and add a second mixin 'B'.

When the second mixin is added, the AbstractBundlePersistenceManager#load(PropertyId) is called to get the current mixins for the node. This method will store the PropertyState for 'jcr:mixinTypes' in the bundle (containing only the mixin 'A'). Then the NodeImpl#setMixinTypesProperty() will set the PropertyState for 'jcr:mixinTypes' in the node state (containing the mixins 'A' and 'B').
When the session is saved, the ChangeLog in AbstractBundlePersistenceManager#store() contains a modification for the 'jcr:mixinTypes' but it's being ignored, leaving the bundle with only mixin 'A'. The NodeIndexer looks into the node state to get the mixin types and indexes the node correctly. The queries '//element(*, 'A')' and '//element(*, 'B')' work.


Thrid step : Select the node and update a property.

When the session is saved, the NodeIndexer asks again for the 'jcr:mixinTypes' property, by calling the AbstractBundlePersistenceManager#load(PropertyId) to load it. The bundle contains this property and returns only mixin 'A' (as it was stored in the second step), causing the index to use only mixin 'A'. The query '//element(*, 'A')' still works but '//element(*, 'B') doesn't work anymore.



A simple solution to this would be to not store the PropertyState for the 'jcr:mixinTypes' (and 'jcr:uuid' and 'jcr:primaryType', as the class description states) in the bundle when the PropertyState is loaded. It would fix the issue but not the contents on existing repositories. One way to allow the repositories to fix themselves is to not read or write these 3 properties in the BundleBinding#readBundle and BundleBinding#writeBundle methods, but I'm not sure wether or not it would have a performance impact.




--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

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

Frederic Laugier updated JCR-1632:
----------------------------------

        Fix Version/s:     (was: 1.5)
    Affects Version/s: 1.5

> Mixin type loss
> ---------------
>
>                 Key: JCR-1632
>                 URL: https://issues.apache.org/jira/browse/JCR-1632
>             Project: Jackrabbit
>          Issue Type: Bug
>          Components: jackrabbit-core
>    Affects Versions: 1.4, 1.5
>         Environment: Linux 64-Bit (openSUSE 10.3) using Java 1.5.0_12 64-Bit
>            Reporter: Frederic Laugier
>
> When using a bundle persistence manager, the mixin type information may be corrupted in the lucene index, causing queries like '//element(*, my:mixin)' to fail.
> The problem is that the 'jcr:mixinTypes' may be stored in the bundle. Here is how this could happen :
> First step: Create a node and add a mixin 'A'.
> Everything's fine. The query '//element(*, 'A')' works.
> Second step : Select the node and add a second mixin 'B'.
> When the second mixin is added, the AbstractBundlePersistenceManager#load(PropertyId) is called to get the current mixins for the node. This method will store the PropertyState for 'jcr:mixinTypes' in the bundle (containing only the mixin 'A'). Then the NodeImpl#setMixinTypesProperty() will set the PropertyState for 'jcr:mixinTypes' in the node state (containing the mixins 'A' and 'B').
> When the session is saved, the ChangeLog in AbstractBundlePersistenceManager#store() contains a modification for the 'jcr:mixinTypes' but it's being ignored, leaving the bundle with only mixin 'A'. The NodeIndexer looks into the node state to get the mixin types and indexes the node correctly. The queries '//element(*, 'A')' and '//element(*, 'B')' work.
> Thrid step : Select the node and update a property.
> When the session is saved, the NodeIndexer asks again for the 'jcr:mixinTypes' property, by calling the AbstractBundlePersistenceManager#load(PropertyId) to load it. The bundle contains this property and returns only mixin 'A' (as it was stored in the second step), causing the index to use only mixin 'A'. The query '//element(*, 'A')' still works but '//element(*, 'B') doesn't work anymore.
> A simple solution to this would be to not store the PropertyState for the 'jcr:mixinTypes' (and 'jcr:uuid' and 'jcr:primaryType', as the class description states) in the bundle when the PropertyState is loaded. It would fix the issue but not the contents on existing repositories. One way to allow the repositories to fix themselves is to not read or write these 3 properties in the BundleBinding#readBundle and BundleBinding#writeBundle methods, but I'm not sure wether or not it would have a performance impact.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

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

Frederic Laugier updated JCR-1632:
----------------------------------

    Attachment: asf-jackrabbit-tests_src.zip

A test suite that shows the issue

> Mixin type loss
> ---------------
>
>                 Key: JCR-1632
>                 URL: https://issues.apache.org/jira/browse/JCR-1632
>             Project: Jackrabbit
>          Issue Type: Bug
>          Components: jackrabbit-core
>    Affects Versions: 1.4, 1.5
>         Environment: Linux 64-Bit (openSUSE 10.3) using Java 1.5.0_12 64-Bit
>            Reporter: Frederic Laugier
>         Attachments: asf-jackrabbit-tests_src.zip
>
>
> When using a bundle persistence manager, the mixin type information may be corrupted in the lucene index, causing queries like '//element(*, my:mixin)' to fail.
> The problem is that the 'jcr:mixinTypes' may be stored in the bundle. Here is how this could happen :
> First step: Create a node and add a mixin 'A'.
> Everything's fine. The query '//element(*, 'A')' works.
> Second step : Select the node and add a second mixin 'B'.
> When the second mixin is added, the AbstractBundlePersistenceManager#load(PropertyId) is called to get the current mixins for the node. This method will store the PropertyState for 'jcr:mixinTypes' in the bundle (containing only the mixin 'A'). Then the NodeImpl#setMixinTypesProperty() will set the PropertyState for 'jcr:mixinTypes' in the node state (containing the mixins 'A' and 'B').
> When the session is saved, the ChangeLog in AbstractBundlePersistenceManager#store() contains a modification for the 'jcr:mixinTypes' but it's being ignored, leaving the bundle with only mixin 'A'. The NodeIndexer looks into the node state to get the mixin types and indexes the node correctly. The queries '//element(*, 'A')' and '//element(*, 'B')' work.
> Thrid step : Select the node and update a property.
> When the session is saved, the NodeIndexer asks again for the 'jcr:mixinTypes' property, by calling the AbstractBundlePersistenceManager#load(PropertyId) to load it. The bundle contains this property and returns only mixin 'A' (as it was stored in the second step), causing the index to use only mixin 'A'. The query '//element(*, 'A')' still works but '//element(*, 'B') doesn't work anymore.
> A simple solution to this would be to not store the PropertyState for the 'jcr:mixinTypes' (and 'jcr:uuid' and 'jcr:primaryType', as the class description states) in the bundle when the PropertyState is loaded. It would fix the issue but not the contents on existing repositories. One way to allow the repositories to fix themselves is to not read or write these 3 properties in the BundleBinding#readBundle and BundleBinding#writeBundle methods, but I'm not sure wether or not it would have a performance impact.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

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

Frederic Laugier updated JCR-1632:
----------------------------------

    Attachment: patch_14

A patch to not store the PropertyState in the bundle for the 1.4 branch

> Mixin type loss
> ---------------
>
>                 Key: JCR-1632
>                 URL: https://issues.apache.org/jira/browse/JCR-1632
>             Project: Jackrabbit
>          Issue Type: Bug
>          Components: jackrabbit-core
>    Affects Versions: 1.4, 1.5
>         Environment: Linux 64-Bit (openSUSE 10.3) using Java 1.5.0_12 64-Bit
>            Reporter: Frederic Laugier
>         Attachments: asf-jackrabbit-tests_src.zip, patch_14
>
>
> When using a bundle persistence manager, the mixin type information may be corrupted in the lucene index, causing queries like '//element(*, my:mixin)' to fail.
> The problem is that the 'jcr:mixinTypes' may be stored in the bundle. Here is how this could happen :
> First step: Create a node and add a mixin 'A'.
> Everything's fine. The query '//element(*, 'A')' works.
> Second step : Select the node and add a second mixin 'B'.
> When the second mixin is added, the AbstractBundlePersistenceManager#load(PropertyId) is called to get the current mixins for the node. This method will store the PropertyState for 'jcr:mixinTypes' in the bundle (containing only the mixin 'A'). Then the NodeImpl#setMixinTypesProperty() will set the PropertyState for 'jcr:mixinTypes' in the node state (containing the mixins 'A' and 'B').
> When the session is saved, the ChangeLog in AbstractBundlePersistenceManager#store() contains a modification for the 'jcr:mixinTypes' but it's being ignored, leaving the bundle with only mixin 'A'. The NodeIndexer looks into the node state to get the mixin types and indexes the node correctly. The queries '//element(*, 'A')' and '//element(*, 'B')' work.
> Thrid step : Select the node and update a property.
> When the session is saved, the NodeIndexer asks again for the 'jcr:mixinTypes' property, by calling the AbstractBundlePersistenceManager#load(PropertyId) to load it. The bundle contains this property and returns only mixin 'A' (as it was stored in the second step), causing the index to use only mixin 'A'. The query '//element(*, 'A')' still works but '//element(*, 'B') doesn't work anymore.
> A simple solution to this would be to not store the PropertyState for the 'jcr:mixinTypes' (and 'jcr:uuid' and 'jcr:primaryType', as the class description states) in the bundle when the PropertyState is loaded. It would fix the issue but not the contents on existing repositories. One way to allow the repositories to fix themselves is to not read or write these 3 properties in the BundleBinding#readBundle and BundleBinding#writeBundle methods, but I'm not sure wether or not it would have a performance impact.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

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

Stefan Guggisberg resolved JCR-1632.
------------------------------------

    Resolution: Fixed

fixed in svn r 679389

> Mixin type loss
> ---------------
>
>                 Key: JCR-1632
>                 URL: https://issues.apache.org/jira/browse/JCR-1632
>             Project: Jackrabbit
>          Issue Type: Bug
>          Components: jackrabbit-core
>    Affects Versions: 1.4, 1.5
>         Environment: Linux 64-Bit (openSUSE 10.3) using Java 1.5.0_12 64-Bit
>            Reporter: Frederic Laugier
>         Attachments: asf-jackrabbit-tests_src.zip, patch_14
>
>
> When using a bundle persistence manager, the mixin type information may be corrupted in the lucene index, causing queries like '//element(*, my:mixin)' to fail.
> The problem is that the 'jcr:mixinTypes' may be stored in the bundle. Here is how this could happen :
> First step: Create a node and add a mixin 'A'.
> Everything's fine. The query '//element(*, 'A')' works.
> Second step : Select the node and add a second mixin 'B'.
> When the second mixin is added, the AbstractBundlePersistenceManager#load(PropertyId) is called to get the current mixins for the node. This method will store the PropertyState for 'jcr:mixinTypes' in the bundle (containing only the mixin 'A'). Then the NodeImpl#setMixinTypesProperty() will set the PropertyState for 'jcr:mixinTypes' in the node state (containing the mixins 'A' and 'B').
> When the session is saved, the ChangeLog in AbstractBundlePersistenceManager#store() contains a modification for the 'jcr:mixinTypes' but it's being ignored, leaving the bundle with only mixin 'A'. The NodeIndexer looks into the node state to get the mixin types and indexes the node correctly. The queries '//element(*, 'A')' and '//element(*, 'B')' work.
> Thrid step : Select the node and update a property.
> When the session is saved, the NodeIndexer asks again for the 'jcr:mixinTypes' property, by calling the AbstractBundlePersistenceManager#load(PropertyId) to load it. The bundle contains this property and returns only mixin 'A' (as it was stored in the second step), causing the index to use only mixin 'A'. The query '//element(*, 'A')' still works but '//element(*, 'B') doesn't work anymore.
> A simple solution to this would be to not store the PropertyState for the 'jcr:mixinTypes' (and 'jcr:uuid' and 'jcr:primaryType', as the class description states) in the bundle when the PropertyState is loaded. It would fix the issue but not the contents on existing repositories. One way to allow the repositories to fix themselves is to not read or write these 3 properties in the BundleBinding#readBundle and BundleBinding#writeBundle methods, but I'm not sure wether or not it would have a performance impact.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

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

Stefan Guggisberg updated JCR-1632:
-----------------------------------

    Fix Version/s: 1.5

> Mixin type loss
> ---------------
>
>                 Key: JCR-1632
>                 URL: https://issues.apache.org/jira/browse/JCR-1632
>             Project: Jackrabbit
>          Issue Type: Bug
>          Components: jackrabbit-core
>    Affects Versions: 1.4, 1.5
>         Environment: Linux 64-Bit (openSUSE 10.3) using Java 1.5.0_12 64-Bit
>            Reporter: Frederic Laugier
>             Fix For: 1.5
>
>         Attachments: asf-jackrabbit-tests_src.zip, patch_14
>
>
> When using a bundle persistence manager, the mixin type information may be corrupted in the lucene index, causing queries like '//element(*, my:mixin)' to fail.
> The problem is that the 'jcr:mixinTypes' may be stored in the bundle. Here is how this could happen :
> First step: Create a node and add a mixin 'A'.
> Everything's fine. The query '//element(*, 'A')' works.
> Second step : Select the node and add a second mixin 'B'.
> When the second mixin is added, the AbstractBundlePersistenceManager#load(PropertyId) is called to get the current mixins for the node. This method will store the PropertyState for 'jcr:mixinTypes' in the bundle (containing only the mixin 'A'). Then the NodeImpl#setMixinTypesProperty() will set the PropertyState for 'jcr:mixinTypes' in the node state (containing the mixins 'A' and 'B').
> When the session is saved, the ChangeLog in AbstractBundlePersistenceManager#store() contains a modification for the 'jcr:mixinTypes' but it's being ignored, leaving the bundle with only mixin 'A'. The NodeIndexer looks into the node state to get the mixin types and indexes the node correctly. The queries '//element(*, 'A')' and '//element(*, 'B')' work.
> Thrid step : Select the node and update a property.
> When the session is saved, the NodeIndexer asks again for the 'jcr:mixinTypes' property, by calling the AbstractBundlePersistenceManager#load(PropertyId) to load it. The bundle contains this property and returns only mixin 'A' (as it was stored in the second step), causing the index to use only mixin 'A'. The query '//element(*, 'A')' still works but '//element(*, 'B') doesn't work anymore.
> A simple solution to this would be to not store the PropertyState for the 'jcr:mixinTypes' (and 'jcr:uuid' and 'jcr:primaryType', as the class description states) in the bundle when the PropertyState is loaded. It would fix the issue but not the contents on existing repositories. One way to allow the repositories to fix themselves is to not read or write these 3 properties in the BundleBinding#readBundle and BundleBinding#writeBundle methods, but I'm not sure wether or not it would have a performance impact.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

    [ https://issues.apache.org/jira/browse/JCR-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616484#action_12616484 ]

Grégory Joseph commented on JCR-1632:
-------------------------------------

Any chance this could be backported to 1.4 ?

> Mixin type loss
> ---------------
>
>                 Key: JCR-1632
>                 URL: https://issues.apache.org/jira/browse/JCR-1632
>             Project: Jackrabbit
>          Issue Type: Bug
>          Components: jackrabbit-core
>    Affects Versions: 1.4, 1.5
>         Environment: Linux 64-Bit (openSUSE 10.3) using Java 1.5.0_12 64-Bit
>            Reporter: Frederic Laugier
>             Fix For: 1.5
>
>         Attachments: asf-jackrabbit-tests_src.zip, patch_14
>
>
> When using a bundle persistence manager, the mixin type information may be corrupted in the lucene index, causing queries like '//element(*, my:mixin)' to fail.
> The problem is that the 'jcr:mixinTypes' may be stored in the bundle. Here is how this could happen :
> First step: Create a node and add a mixin 'A'.
> Everything's fine. The query '//element(*, 'A')' works.
> Second step : Select the node and add a second mixin 'B'.
> When the second mixin is added, the AbstractBundlePersistenceManager#load(PropertyId) is called to get the current mixins for the node. This method will store the PropertyState for 'jcr:mixinTypes' in the bundle (containing only the mixin 'A'). Then the NodeImpl#setMixinTypesProperty() will set the PropertyState for 'jcr:mixinTypes' in the node state (containing the mixins 'A' and 'B').
> When the session is saved, the ChangeLog in AbstractBundlePersistenceManager#store() contains a modification for the 'jcr:mixinTypes' but it's being ignored, leaving the bundle with only mixin 'A'. The NodeIndexer looks into the node state to get the mixin types and indexes the node correctly. The queries '//element(*, 'A')' and '//element(*, 'B')' work.
> Thrid step : Select the node and update a property.
> When the session is saved, the NodeIndexer asks again for the 'jcr:mixinTypes' property, by calling the AbstractBundlePersistenceManager#load(PropertyId) to load it. The bundle contains this property and returns only mixin 'A' (as it was stored in the second step), causing the index to use only mixin 'A'. The query '//element(*, 'A')' still works but '//element(*, 'B') doesn't work anymore.
> A simple solution to this would be to not store the PropertyState for the 'jcr:mixinTypes' (and 'jcr:uuid' and 'jcr:primaryType', as the class description states) in the bundle when the PropertyState is loaded. It would fix the issue but not the contents on existing repositories. One way to allow the repositories to fix themselves is to not read or write these 3 properties in the BundleBinding#readBundle and BundleBinding#writeBundle methods, but I'm not sure wether or not it would have a performance impact.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

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

Jukka Zitting updated JCR-1632:
-------------------------------

    Fix Version/s:     (was: 1.5)
                   core 1.4.6

No problem. Merged to the 1.4 branch in revision 679425. Would you like us to make an official jackrabbit-core 1.4.6 release with this fix?

> Mixin type loss
> ---------------
>
>                 Key: JCR-1632
>                 URL: https://issues.apache.org/jira/browse/JCR-1632
>             Project: Jackrabbit
>          Issue Type: Bug
>          Components: jackrabbit-core
>    Affects Versions: 1.4, 1.5
>         Environment: Linux 64-Bit (openSUSE 10.3) using Java 1.5.0_12 64-Bit
>            Reporter: Frederic Laugier
>             Fix For: core 1.4.6
>
>         Attachments: asf-jackrabbit-tests_src.zip, patch_14
>
>
> When using a bundle persistence manager, the mixin type information may be corrupted in the lucene index, causing queries like '//element(*, my:mixin)' to fail.
> The problem is that the 'jcr:mixinTypes' may be stored in the bundle. Here is how this could happen :
> First step: Create a node and add a mixin 'A'.
> Everything's fine. The query '//element(*, 'A')' works.
> Second step : Select the node and add a second mixin 'B'.
> When the second mixin is added, the AbstractBundlePersistenceManager#load(PropertyId) is called to get the current mixins for the node. This method will store the PropertyState for 'jcr:mixinTypes' in the bundle (containing only the mixin 'A'). Then the NodeImpl#setMixinTypesProperty() will set the PropertyState for 'jcr:mixinTypes' in the node state (containing the mixins 'A' and 'B').
> When the session is saved, the ChangeLog in AbstractBundlePersistenceManager#store() contains a modification for the 'jcr:mixinTypes' but it's being ignored, leaving the bundle with only mixin 'A'. The NodeIndexer looks into the node state to get the mixin types and indexes the node correctly. The queries '//element(*, 'A')' and '//element(*, 'B')' work.
> Thrid step : Select the node and update a property.
> When the session is saved, the NodeIndexer asks again for the 'jcr:mixinTypes' property, by calling the AbstractBundlePersistenceManager#load(PropertyId) to load it. The bundle contains this property and returns only mixin 'A' (as it was stored in the second step), causing the index to use only mixin 'A'. The query '//element(*, 'A')' still works but '//element(*, 'B') doesn't work anymore.
> A simple solution to this would be to not store the PropertyState for the 'jcr:mixinTypes' (and 'jcr:uuid' and 'jcr:primaryType', as the class description states) in the bundle when the PropertyState is loaded. It would fix the issue but not the contents on existing repositories. One way to allow the repositories to fix themselves is to not read or write these 3 properties in the BundleBinding#readBundle and BundleBinding#writeBundle methods, but I'm not sure wether or not it would have a performance impact.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

    [ https://issues.apache.org/jira/browse/JCR-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616533#action_12616533 ]

Grégory Joseph commented on JCR-1632:
-------------------------------------

wow that'd be awesome :)

> Mixin type loss
> ---------------
>
>                 Key: JCR-1632
>                 URL: https://issues.apache.org/jira/browse/JCR-1632
>             Project: Jackrabbit
>          Issue Type: Bug
>          Components: jackrabbit-core
>    Affects Versions: 1.4, 1.5
>         Environment: Linux 64-Bit (openSUSE 10.3) using Java 1.5.0_12 64-Bit
>            Reporter: Frederic Laugier
>             Fix For: core 1.4.6
>
>         Attachments: asf-jackrabbit-tests_src.zip, patch_14
>
>
> When using a bundle persistence manager, the mixin type information may be corrupted in the lucene index, causing queries like '//element(*, my:mixin)' to fail.
> The problem is that the 'jcr:mixinTypes' may be stored in the bundle. Here is how this could happen :
> First step: Create a node and add a mixin 'A'.
> Everything's fine. The query '//element(*, 'A')' works.
> Second step : Select the node and add a second mixin 'B'.
> When the second mixin is added, the AbstractBundlePersistenceManager#load(PropertyId) is called to get the current mixins for the node. This method will store the PropertyState for 'jcr:mixinTypes' in the bundle (containing only the mixin 'A'). Then the NodeImpl#setMixinTypesProperty() will set the PropertyState for 'jcr:mixinTypes' in the node state (containing the mixins 'A' and 'B').
> When the session is saved, the ChangeLog in AbstractBundlePersistenceManager#store() contains a modification for the 'jcr:mixinTypes' but it's being ignored, leaving the bundle with only mixin 'A'. The NodeIndexer looks into the node state to get the mixin types and indexes the node correctly. The queries '//element(*, 'A')' and '//element(*, 'B')' work.
> Thrid step : Select the node and update a property.
> When the session is saved, the NodeIndexer asks again for the 'jcr:mixinTypes' property, by calling the AbstractBundlePersistenceManager#load(PropertyId) to load it. The bundle contains this property and returns only mixin 'A' (as it was stored in the second step), causing the index to use only mixin 'A'. The query '//element(*, 'A')' still works but '//element(*, 'B') doesn't work anymore.
> A simple solution to this would be to not store the PropertyState for the 'jcr:mixinTypes' (and 'jcr:uuid' and 'jcr:primaryType', as the class description states) in the bundle when the PropertyState is loaded. It would fix the issue but not the contents on existing repositories. One way to allow the repositories to fix themselves is to not read or write these 3 properties in the BundleBinding#readBundle and BundleBinding#writeBundle methods, but I'm not sure wether or not it would have a performance impact.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.