[jira] [Comment Edited] (JCRVLT-128) System maintained cache nodes should be ignored
[ https://issues.apache.org/jira/browse/JCRVLT-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15564547#comment-15564547 ] Tobias Bocanegra edited comment on JCRVLT-128 at 10/11/16 7:57 AM: --- ok. i could reproduce it: 1. change usermanager configuration to enable cache (see https://jackrabbit.apache.org/oak/docs/security/principal/cache.html) 2. create a user XYZ 3. create a package of this user. doesn't really matter if it contains the cache node or not, or if it's exlucded by the filter. 4. delete the user, and recreate it (basically move it to a different location, due to the random path algo) 5. assign a group and login as this user 6. verify that the user now has a cache node 7. install the package from above: {{org.apache.jackrabbit.vault.packaging.PackageException: javax.jcr.nodetype.ConstraintViolationException: OakConstraint0034: Attempt to create or change the system maintained cache.}} Added test case in: r1764211 was (Author: tripod): ok. i could reproduce it: 1. change usermanager configuration to enable cache (see https://jackrabbit.apache.org/oak/docs/security/principal/cache.html) 2. create a user XYZ 3. create a package of this user. doesn't really matter if it contains the cache node or not, or if it's exlucded by the filter. 4. delete the user, and recreate it (basically move it to a different location, due to the random path algo) 5. assign a group and login as this user 6. verify that the user now has a cache node 7. install the package from above: {{org.apache.jackrabbit.vault.packaging.PackageException: javax.jcr.nodetype.ConstraintViolationException: OakConstraint0034: Attempt to create or change the system maintained cache.}} > System maintained cache nodes should be ignored > --- > > Key: JCRVLT-128 > URL: https://issues.apache.org/jira/browse/JCRVLT-128 > Project: Jackrabbit FileVault > Issue Type: Bug >Affects Versions: 3.1.28 >Reporter: Tommaso Teofili >Assignee: Tobias Bocanegra > Attachments: JCRVLT-128.0.patch > > > In OAK-3003 a persisted [principal > cache|http://jackrabbit.apache.org/oak/docs/security/principal/cache.html] > was introduced that creates _rep:cache_ nodes under authorizables. > Creating a package for such authorizables will result in including the cache > node in there, which sounds wrong as that node is an implementation detail > which doesn't make sense to install anywhere; however that can be avoided by > proper filters. > What is problematic is the installation phase, if an authorizable gets > packaged with FileVault (no rep:cache in the package) and the target > user/group has a rep:cache node itself the importer will try (and fail as > it's protected) to delete the persisted cache node if ImportMode is set to > UPDATE. > In my opinion this is wrong, it should be possible to not touch such nodes on > package installation, regardless of the chosen ImportMode. > {noformat} > org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage Error during > install. > javax.jcr.nodetype.ConstraintViolationException: OakConstraint0034: Attempt > to create or change the system maintained cache. > at > org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:225) > at > org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:212) > at > org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.newRepositoryException(SessionDelegate.java:670) > at > org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.save(SessionDelegate.java:496) > at > org.apache.jackrabbit.oak.jcr.session.SessionImpl$8.performVoid(SessionImpl.java:419) > at > org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.performVoid(SessionDelegate.java:274) > at > org.apache.jackrabbit.oak.jcr.session.SessionImpl.save(SessionImpl.java:416) > at org.apache.jackrabbit.vault.fs.io.AutoSave.save(AutoSave.java:175) > at org.apache.jackrabbit.vault.fs.io.Importer.run(Importer.java:416) > at > org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.extract(ZipVaultPackage.java:234) > at > org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.extract(ZipVaultPackage.java:153) > {noformat} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (JCRVLT-128) System maintained cache nodes should be ignored
[ https://issues.apache.org/jira/browse/JCRVLT-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15522208#comment-15522208 ] Tobias Bocanegra edited comment on JCRVLT-128 at 9/26/16 6:27 AM: -- [~teofili] I fixed something in r1762273 \[0\] but I don't know if it helps. I have a hard time to reproduce this. [~anchela] how can I create a user that has a {{rep:cache}} node? \[0\] http://svn.apache.org/viewvc/jackrabbit/commons/filevault/trunk/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/DocViewSAXImporter.java?r1=1762273&r2=1762272&pathrev=1762273 was (Author: tripod): [~teofili] I fixed something in r1762273 but I don't know if it helps. I have a hard time to reproduce this. [~anchela] how can I create a user that has a {{rep:cache}} node? > System maintained cache nodes should be ignored > --- > > Key: JCRVLT-128 > URL: https://issues.apache.org/jira/browse/JCRVLT-128 > Project: Jackrabbit FileVault > Issue Type: Bug >Affects Versions: 3.1.28 >Reporter: Tommaso Teofili >Assignee: Tobias Bocanegra > Attachments: JCRVLT-128.0.patch > > > In OAK-3003 a persisted [principal > cache|http://jackrabbit.apache.org/oak/docs/security/principal/cache.html] > was introduced that creates _rep:cache_ nodes under authorizables. > Creating a package for such authorizables will result in including the cache > node in there, which sounds wrong as that node is an implementation detail > which doesn't make sense to install anywhere; however that can be avoided by > proper filters. > What is problematic is the installation phase, if an authorizable gets > packaged with FileVault (no rep:cache in the package) and the target > user/group has a rep:cache node itself the importer will try (and fail as > it's protected) to delete the persisted cache node if ImportMode is set to > UPDATE. > In my opinion this is wrong, it should be possible to not touch such nodes on > package installation, regardless of the chosen ImportMode. > {noformat} > org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage Error during > install. > javax.jcr.nodetype.ConstraintViolationException: OakConstraint0034: Attempt > to create or change the system maintained cache. > at > org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:225) > at > org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:212) > at > org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.newRepositoryException(SessionDelegate.java:670) > at > org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.save(SessionDelegate.java:496) > at > org.apache.jackrabbit.oak.jcr.session.SessionImpl$8.performVoid(SessionImpl.java:419) > at > org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.performVoid(SessionDelegate.java:274) > at > org.apache.jackrabbit.oak.jcr.session.SessionImpl.save(SessionImpl.java:416) > at org.apache.jackrabbit.vault.fs.io.AutoSave.save(AutoSave.java:175) > at org.apache.jackrabbit.vault.fs.io.Importer.run(Importer.java:416) > at > org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.extract(ZipVaultPackage.java:234) > at > org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.extract(ZipVaultPackage.java:153) > {noformat} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (JCRVLT-128) System maintained cache nodes should be ignored
[ https://issues.apache.org/jira/browse/JCRVLT-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15509810#comment-15509810 ] Tommaso Teofili edited comment on JCRVLT-128 at 9/21/16 1:19 PM: - attaching dummy patch which avoids restoring _rep:cache_ nodes from stashed ones in {{JcrSysViewTransformer}}; so the side effect is that the cache nodes are removed after package installation. [~tripod] WDYT? I'm pretty sure there's a better way of doing that. was (Author: teofili): attaching dummy patch which avoids restoring _rep:cache_ nodes from stashed ones in {{JcrSysViewTransformer}}, [~tripod] WDYT? I'm pretty sure there's a better way of doing that. > System maintained cache nodes should be ignored > --- > > Key: JCRVLT-128 > URL: https://issues.apache.org/jira/browse/JCRVLT-128 > Project: Jackrabbit FileVault > Issue Type: Bug >Affects Versions: 3.1.28 >Reporter: Tommaso Teofili > Attachments: JCRVLT-128.0.patch > > > In OAK-3003 a persisted [principal > cache|http://jackrabbit.apache.org/oak/docs/security/principal/cache.html] > was introduced that creates _rep:cache_ nodes under authorizables. > Creating a package for such authorizables will result in including the cache > node in there, which sounds wrong as that node is an implementation detail > which doesn't make sense to install anywhere; however that can be avoided by > proper filters. > What is problematic is the installation phase, if an authorizable gets > packaged with FileVault (no rep:cache in the package) and the target > user/group has a rep:cache node itself the importer will try (and fail as > it's protected) to delete the persisted cache node if ImportMode is set to > UPDATE. > In my opinion this is wrong, it should be possible to not touch such nodes on > package installation, regardless of the chosen ImportMode. > {noformat} > org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage Error during > install. > javax.jcr.nodetype.ConstraintViolationException: OakConstraint0034: Attempt > to create or change the system maintained cache. > at > org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:225) > at > org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:212) > at > org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.newRepositoryException(SessionDelegate.java:670) > at > org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.save(SessionDelegate.java:496) > at > org.apache.jackrabbit.oak.jcr.session.SessionImpl$8.performVoid(SessionImpl.java:419) > at > org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.performVoid(SessionDelegate.java:274) > at > org.apache.jackrabbit.oak.jcr.session.SessionImpl.save(SessionImpl.java:416) > at org.apache.jackrabbit.vault.fs.io.AutoSave.save(AutoSave.java:175) > at org.apache.jackrabbit.vault.fs.io.Importer.run(Importer.java:416) > at > org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.extract(ZipVaultPackage.java:234) > at > org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.extract(ZipVaultPackage.java:153) > {noformat} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (JCRVLT-128) System maintained cache nodes should be ignored
[ https://issues.apache.org/jira/browse/JCRVLT-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15509810#comment-15509810 ] Tommaso Teofili edited comment on JCRVLT-128 at 9/21/16 1:10 PM: - attaching dummy patch which avoids restoring _rep:cache_ nodes from stashed ones in {{JcrSysViewTransformer}}, [~tripod] WDYT? I'm pretty sure there's a better way of doing that. was (Author: teofili): attaching dummy patch which avoids adding _rep:cache_ in {{JcrSysViewTransformer}}, [~tripod] WDYT? I'm pretty sure there's a better way of doing that. > System maintained cache nodes should be ignored > --- > > Key: JCRVLT-128 > URL: https://issues.apache.org/jira/browse/JCRVLT-128 > Project: Jackrabbit FileVault > Issue Type: Bug >Affects Versions: 3.1.28 >Reporter: Tommaso Teofili > Attachments: JCRVLT-128.0.patch > > > In OAK-3003 a persisted [principal > cache|http://jackrabbit.apache.org/oak/docs/security/principal/cache.html] > was introduced that creates _rep:cache_ nodes under authorizables. > Creating a package for such authorizables will result in including the cache > node in there, which sounds wrong as that node is an implementation detail > which doesn't make sense to install anywhere; however that can be avoided by > proper filters. > What is problematic is the installation phase, if an authorizable gets > packaged with FileVault (no rep:cache in the package) and the target > user/group has a rep:cache node itself the importer will try (and fail as > it's protected) to delete the persisted cache node if ImportMode is set to > UPDATE. > In my opinion this is wrong, it should be possible to not touch such nodes on > package installation, regardless of the chosen ImportMode. > {noformat} > org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage Error during > install. > javax.jcr.nodetype.ConstraintViolationException: OakConstraint0034: Attempt > to create or change the system maintained cache. > at > org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:225) > at > org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:212) > at > org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.newRepositoryException(SessionDelegate.java:670) > at > org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.save(SessionDelegate.java:496) > at > org.apache.jackrabbit.oak.jcr.session.SessionImpl$8.performVoid(SessionImpl.java:419) > at > org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.performVoid(SessionDelegate.java:274) > at > org.apache.jackrabbit.oak.jcr.session.SessionImpl.save(SessionImpl.java:416) > at org.apache.jackrabbit.vault.fs.io.AutoSave.save(AutoSave.java:175) > at org.apache.jackrabbit.vault.fs.io.Importer.run(Importer.java:416) > at > org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.extract(ZipVaultPackage.java:234) > at > org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.extract(ZipVaultPackage.java:153) > {noformat} -- This message was sent by Atlassian JIRA (v6.3.4#6332)