[jira] [Updated] (JCRVLT-128) System maintained cache nodes should be ignored
[
https://issues.apache.org/jira/browse/JCRVLT-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili updated JCRVLT-128:
---
Attachment: JCRVLT-128.0.patch
> 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] [Updated] (JCRVLT-128) System maintained cache nodes should be ignored
[
https://issues.apache.org/jira/browse/JCRVLT-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili updated JCRVLT-128:
---
Attachment: (was: JCRVLT-128.0.patch)
> 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
>
> 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] [Updated] (JCRVLT-128) System maintained cache nodes should be ignored
[
https://issues.apache.org/jira/browse/JCRVLT-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili updated JCRVLT-128:
---
Attachment: JCRVLT-128.0.patch
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)
[jira] [Updated] (JCRVLT-128) System maintained cache nodes should be ignored
[
https://issues.apache.org/jira/browse/JCRVLT-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili updated JCRVLT-128:
---
Description:
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}
was:
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 unless the ImportMode is set to MERGE.
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}
> 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
>
> In OAK-3
[jira] [Updated] (JCRVLT-128) System maintained cache nodes should be ignored
[
https://issues.apache.org/jira/browse/JCRVLT-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili updated JCRVLT-128:
---
Description:
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 unless the ImportMode is set to MERGE.
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}
was:
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 unless the ImportMode is set to MERGE.
In my opinion this is wrong, it should be possible to not touch such nodes on
package installation, regardless of the chosen ImportMode.
> 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
>
> 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 unless the ImportMode is
> set to MERGE.
> 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(Co
