[ 
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-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)

Reply via email to