[jira] [Closed] (JCRVLT-129) Update commons-httpclient to 3.1
[ https://issues.apache.org/jira/browse/JCRVLT-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Bocanegra closed JCRVLT-129. --- > Update commons-httpclient to 3.1 > > > Key: JCRVLT-129 > URL: https://issues.apache.org/jira/browse/JCRVLT-129 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: vlt >Affects Versions: 3.1.28 >Reporter: Tobias Bocanegra >Assignee: Tobias Bocanegra >Priority: Trivial > Fix For: 3.1.30 > > > update httpclient version to recent version. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (JCRVLT-130) Installing package with versions fails if the node is checked in
[ https://issues.apache.org/jira/browse/JCRVLT-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Bocanegra closed JCRVLT-130. --- > Installing package with versions fails if the node is checked in > > > Key: JCRVLT-130 > URL: https://issues.apache.org/jira/browse/JCRVLT-130 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: Packaging >Affects Versions: 3.1.28 >Reporter: Tobias Bocanegra >Assignee: Tobias Bocanegra > Fix For: 3.1.30 > > > If the package contains a versionable node that is already checked in on the > destination repository, the import fails. > this is probably a regression. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (JCRVLT-106) Importing an user and children with UPDATE mode causes unnecessary warnings
[
https://issues.apache.org/jira/browse/JCRVLT-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra closed JCRVLT-106.
---
> Importing an user and children with UPDATE mode causes unnecessary warnings
> ---
>
> Key: JCRVLT-106
> URL: https://issues.apache.org/jira/browse/JCRVLT-106
> Project: Jackrabbit FileVault
> Issue Type: Bug
>Affects Versions: 3.1.24
>Reporter: Marius Petria
>Assignee: Tobias Bocanegra
>Priority: Minor
> Fix For: 3.1.30
>
> Attachments: JCRVLT-106.patch
>
>
> Importing an user and children with UPDATE mode causes unnecessary warnings.
> Assume a package with a {{testuser}} and a child node {{profile}}. Installing
> the package twice with {{UPDATE}} mode will trigger some warnings at the
> second install.
> {noformat}
> org.apache.jackrabbit.vault.fs.impl.io.JcrSysViewTransformer Unable to move
> child back to new location
> {noformat}
> That happens because the profile node is saved in a temporary location but
> when it needs to be restored [1] (or [2] in trunk) the move fails because
> profile node already exists under the newly recreated user. We could mitigate
> the unnecessary warning by first checking if the child node already exists
> before trying a move.
> [1]
> https://github.com/apache/jackrabbit-filevault/blob/95e769cefce3199e7351118129d3358828f206d8/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/JcrSysViewTransformer.java#L138
> [2]
> https://github.com/apache/jackrabbit-filevault/blob/944fdcb23fc6707d1dd844586a2abbb26ca30d49/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/ChildNodeStash.java#L130
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (JCRVLT-126) Content packages update content outside of their filters if ancestor node have binary property
[ https://issues.apache.org/jira/browse/JCRVLT-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Bocanegra closed JCRVLT-126. --- > Content packages update content outside of their filters if ancestor node > have binary property > -- > > Key: JCRVLT-126 > URL: https://issues.apache.org/jira/browse/JCRVLT-126 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: Packaging >Affects Versions: 3.1.26 >Reporter: Masayuki Imai >Assignee: Tobias Bocanegra > Fix For: 3.1.30 > > Attachments: filter-problem-1.0.zip > > > *[Problem]* > If ancestor nodes of specified node as filter have binary property, The > package will update the ancestor nodes. > The package install role user can't install the project package if the user > don't have write permission for ancestor nodes. > - For all filters all binary properties of ancestor nodes will be wrapped and > be installed even when not being part of the binary > - Even adding a negative look ahead exclude (exclude all .binary not > following the root path) does not work. > *[Reproducible package]* > I attached reproducible package. > filter-problem-1.0.zip > *[Expected behavior]* > The package don't update the property of the ancestor nodes of filter > specified node even if the ancestor nodes have binary property. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (JCRVLT-111) Add support for o.a.j.api.security.authorization.PrincipalSetPolicy
[
https://issues.apache.org/jira/browse/JCRVLT-111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra closed JCRVLT-111.
---
> Add support for o.a.j.api.security.authorization.PrincipalSetPolicy
> ---
>
> Key: JCRVLT-111
> URL: https://issues.apache.org/jira/browse/JCRVLT-111
> Project: Jackrabbit FileVault
> Issue Type: New Feature
>Reporter: angela
>Assignee: Tobias Bocanegra
> Fix For: 3.1.30
>
> Attachments: JCRVLT-111.patch
>
>
> jackrabbit API has been extended by an additional type of access control
> policy, which isn't an ACL. fvault should be adjusted to be able to properly
> import that type of access control policy.
> as discussed: ac-handling {{MERGE}} and {{MERGE_PRESERVE}} should be
> implemented the same way and just add extra principal names that are not yet
> present in the set.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[RESULT][VOTE] Release Apache Jackrabbit Filevault 3.1.30
Hello Team, the vote passes as follows: +1 Tobias Bocanegra +1 Marcel Reutegger +1 Dominique Jaeggi Thanks for voting. I'll push the release out. On Thu, Sep 29, 2016 at 6:19 PM, Dominique Jaeggi wrote: > [X] +1 Release this package as Apache Jackrabbit Filevault 3.1.30 >
[jira] [Commented] (JCR-4037) add includeSubtreeOnDelete flag to JackrabbitEventFilter
[
https://issues.apache.org/jira/browse/JCR-4037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15532940#comment-15532940
]
Stefan Egli commented on JCR-4037:
--
Don't know. But we could make that explicit too by introducing
{{includeSubtreeOnMove}} ?
> add includeSubtreeOnDelete flag to JackrabbitEventFilter
>
>
> Key: JCR-4037
> URL: https://issues.apache.org/jira/browse/JCR-4037
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: observation
>Affects Versions: 2.13.3
>Reporter: Stefan Egli
>
> In some cases of observation it would be useful to receive events of child
> node or properties of a parent/grandparent that was deleted. Currently (in
> Oak at least) one only receives a deleted event for the node that was deleted
> and none of the children.
> Suggesting to (re)introduce a flag, eg as follows to the
> JackrabbitEventFilter:
> {code}
> boolean includeSubtreeOnDelete;
> {code}
> (Open for any better name of course)
> /cc [~mduerig], [~mreutegg]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCR-4037) add includeSubtreeOnDelete flag to JackrabbitEventFilter
[
https://issues.apache.org/jira/browse/JCR-4037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15532884#comment-15532884
]
Michael Dürig commented on JCR-4037:
Would that flag include deletes implied by a move operation or not? No
preferences from my side. We just need to be clear.
> add includeSubtreeOnDelete flag to JackrabbitEventFilter
>
>
> Key: JCR-4037
> URL: https://issues.apache.org/jira/browse/JCR-4037
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: observation
>Affects Versions: 2.13.3
>Reporter: Stefan Egli
>
> In some cases of observation it would be useful to receive events of child
> node or properties of a parent/grandparent that was deleted. Currently (in
> Oak at least) one only receives a deleted event for the node that was deleted
> and none of the children.
> Suggesting to (re)introduce a flag, eg as follows to the
> JackrabbitEventFilter:
> {code}
> boolean includeSubtreeOnDelete;
> {code}
> (Open for any better name of course)
> /cc [~mduerig], [~mreutegg]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCR-4037) add includeSubtreeOnDelete flag to JackrabbitEventFilter
[
https://issues.apache.org/jira/browse/JCR-4037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15532807#comment-15532807
]
Stefan Egli commented on JCR-4037:
--
Note that the default for this should be false in oak, as that's how it behaves
currently.
> add includeSubtreeOnDelete flag to JackrabbitEventFilter
>
>
> Key: JCR-4037
> URL: https://issues.apache.org/jira/browse/JCR-4037
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: observation
>Affects Versions: 2.13.3
>Reporter: Stefan Egli
>
> In some cases of observation it would be useful to receive events of child
> node or properties of a parent/grandparent that was deleted. Currently (in
> Oak at least) one only receives a deleted event for the node that was deleted
> and none of the children.
> Suggesting to (re)introduce a flag, eg as follows to the
> JackrabbitEventFilter:
> {code}
> boolean includeSubtreeOnDelete;
> {code}
> (Open for any better name of course)
> /cc [~mduerig], [~mreutegg]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (JCR-4037) add includeSubtreeOnDelete flag to JackrabbitEventFilter
Stefan Egli created JCR-4037:
Summary: add includeSubtreeOnDelete flag to JackrabbitEventFilter
Key: JCR-4037
URL: https://issues.apache.org/jira/browse/JCR-4037
Project: Jackrabbit Content Repository
Issue Type: Improvement
Components: observation
Affects Versions: 2.13.3
Reporter: Stefan Egli
In some cases of observation it would be useful to receive events of child node
or properties of a parent/grandparent that was deleted. Currently (in Oak at
least) one only receives a deleted event for the node that was deleted and none
of the children.
Suggesting to (re)introduce a flag, eg as follows to the JackrabbitEventFilter:
{code}
boolean includeSubtreeOnDelete;
{code}
(Open for any better name of course)
/cc [~mduerig], [~mreutegg]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: [VOTE] Release Apache Jackrabbit Filevault 3.1.30
[X] +1 Release this package as Apache Jackrabbit Filevault 3.1.30
[jira] [Commented] (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=15532271#comment-15532271
]
Tobias Bocanegra commented on JCRVLT-128:
-
hmm...ok. I check again.
> 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] [Commented] (JCR-4017) add ignoresInfo flag to JackrabbitEventFilter
[
https://issues.apache.org/jira/browse/JCR-4017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15532215#comment-15532215
]
Stefan Egli commented on JCR-4017:
--
See [related
discussion|https://issues.apache.org/jira/browse/OAK-4759?focusedCommentId=15506601&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15506601]
on OAK-4759 re introducing a {{IgnoresCommitInfo}} (instead of perhaps a
{{boolean ignoresEventInfo;}}
> add ignoresInfo flag to JackrabbitEventFilter
> -
>
> Key: JCR-4017
> URL: https://issues.apache.org/jira/browse/JCR-4017
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: observation
>Affects Versions: 2.13.3
>Reporter: Stefan Egli
>
> Some EventListeners aren't really interested in the info {{Map}} the
> {{onEvent}} ie {{Event}} comes with. However, maintaining that {{Map}} can be
> costly. It would be more efficient if listeners could express that they're
> not at all interested in this map and that Jackrabbit/Oak can filter it.
> Suggestion is therefore to extend JackrabbitEventFilter with:
> {code}
> boolean ignoresEventInfo;
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (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=15532185#comment-15532185
]
Tommaso Teofili commented on JCRVLT-128:
the reason why I had thought it is for REPLACE is that I see the special
handling is guarded by _if (wspFilter.getImportMode(path) ==
ImportMode.REPLACE)_. However I agree we need a test in order to fix and guard
from any regression there.
> 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)
