[jira] [Commented] (JCRVLT-745) Stashing: naming and folder location
[ https://issues.apache.org/jira/browse/JCRVLT-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17818541#comment-17818541 ] Tobias Bocanegra commented on JCRVLT-745: - sorry, no. > Stashing: naming and folder location > > > Key: JCRVLT-745 > URL: https://issues.apache.org/jira/browse/JCRVLT-745 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: vlt >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > > We have seen cases where node stashing failed due to RuntimeExceptions (OOM > or MongoDB issues in Oak). In these cases, the tmp folder is not cleaned up. > If the operation is retried many times, there'll be many of these. > Suggestion: > 1. Do not use the root as default location, > 2. Introduce an intermediary node that makes it clear that this is temp space > created by FileVault. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCRVLT-691) The escaping "\0" is also used for single value Binary and String properties
[
https://issues.apache.org/jira/browse/JCRVLT-691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693610#comment-17693610
]
Tobias Bocanegra commented on JCRVLT-691:
-
sorry. I can't remember.
> The escaping "\0" is also used for single value Binary and String properties
>
>
> Key: JCRVLT-691
> URL: https://issues.apache.org/jira/browse/JCRVLT-691
> Project: Jackrabbit FileVault
> Issue Type: Improvement
>Reporter: Konrad Windszus
>Priority: Minor
>
> In JCRVLT-4 a special escaping for a multi-value property containing only a
> single value with the empty string was introduced. This escaping is also used
> for single-value String and Binary, although those are not ambiguous.
> The parsing of those values doesn't differ though whether it is containing
> the {{\0}} or not, but it would be good to omit those unnecessary characters
> in the serialization.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JCRVLT-670) Upgrade to commons-collections4
[ https://issues.apache.org/jira/browse/JCRVLT-670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17647952#comment-17647952 ] Tobias Bocanegra commented on JCRVLT-670: - IIRC, the goal was indeed to reduce the amount of retained memory for the names of the aggregates. for large repos, this was significant. But this was for java 1.4 maybe the string memory handling has improved since then. I think removing the caching is certainly a valid approach. > Upgrade to commons-collections4 > --- > > Key: JCRVLT-670 > URL: https://issues.apache.org/jira/browse/JCRVLT-670 > Project: Jackrabbit FileVault > Issue Type: Task >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > > Some code uses the EOLd commons-collections, based on a leaking transitive > dependency from Jackrabbit code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCRVLT-598) need IdConflictPolicy compatible with 3.5.0 behavior
[ https://issues.apache.org/jira/browse/JCRVLT-598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17552705#comment-17552705 ] Tobias Bocanegra commented on JCRVLT-598: - In general, we don't support updating ref. nodes at different locations, since it's usually not what the user expects. but if the node has the same parent, it was probably just renamed, and then it's reused. (I think this was the reasoning) > need IdConflictPolicy compatible with 3.5.0 behavior > > > Key: JCRVLT-598 > URL: https://issues.apache.org/jira/browse/JCRVLT-598 > Project: Jackrabbit FileVault > Issue Type: Sub-task > Components: vlt >Affects Versions: 3.5.8 >Reporter: Julian Reschke >Assignee: Konrad Windszus >Priority: Major > Fix For: 3.6.2 > > Attachments: test-duplicate-referencable-on-child-element-only.zip, > test-referenceable.zip > > > Currently, according to the documentation > ([https://jackrabbit.apache.org/filevault/referenceablenodes.html]), > "IdConflictPolicy.FORCE_REMOVE_CONFLICTING_ID" is supposed to behave as 3.5.0 > did. > My tests show however that in 3.5.0, when importing a package with two nodes > with conflicting UUIDs, both nodes were imported (and one of the UUIDs > changed). > Update: It turned out that this is only the conflict handling for non-sibling > nodes, for sibling nodes the behaviour depends on whether the existing > conflicting node is contained in the filter or not. If it is contained the > to-be imported node just replaced the conflicting node, if it is not > contained, the to-be imported node is just skipped! > From that point of view, CREATE_NEW_ID seems to be closer (but that one > assigns new UUIDs to *both* nodes). > -Proposal: adjust CREATE_NEW_ID behavior to keep assigning a new UUID only > when needed (thus preserving it for one of the nodes), and document *that* > mode as compatible to 3.5.0.- > Updated Proposal: Create new IdConflictPolicy.LEGACY which removes > conflicting nodes in case they are siblings (i.e. share the same parent > node), otherwise will create a new ID for the to be imported referencable node -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (JCRVLT-522) Authorizable and authorization nodes applied even if filter rules exclude them
[
https://issues.apache.org/jira/browse/JCRVLT-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17479175#comment-17479175
]
Tobias Bocanegra commented on JCRVLT-522:
-
I think only *2.* is inconsistent, right? so this could be fixed, by no
installing the ACL.
> Authorizable and authorization nodes applied even if filter rules exclude them
> --
>
> Key: JCRVLT-522
> URL: https://issues.apache.org/jira/browse/JCRVLT-522
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: Packaging
>Affects Versions: 3.4.10
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.5.10
>
>
> Currently the filter rules are not fully evaluated prior to applying ACLs (in
> rep:policy and rep:repoPolicy files). According to JCRVLT-372 this is a bug.
> The same is true for authorizable nodes (compare with JCRVLT-71).
> The exact install behaviour is as follows (given that the ACHandling is not
> IGNORE):
>
> || ||Path in Filter?||Effect||Example ACL Path(s)||Example Content Node
> Path(s)||
> ||1|Contained in
> filter|Installed|/testroot/node_a/rep:policy|/testroot/node_a||
> ||2|Not contained in filter, but ancestor is
> contained|Installed|/testroot/secured/rep:policy|testroot/secured||
> ||3|Neither path nor ancestor is contained in filter|Not
> Installed|/test2/rep:policy|/test2||
> ||4|Path is not contained in filter, ancestor is not contained either, but
> node affected by ACLs is contained|Not
> Installed|/testroot/rep:policy|/testroot||
> The example columns assume the following filter.xml
> {code}
>
>
>
>
>
>
>
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (JCRVLT-582) Package import fails for namespaced paths and path mapping
[
https://issues.apache.org/jira/browse/JCRVLT-582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17475970#comment-17475970
]
Tobias Bocanegra commented on JCRVLT-582:
-
yes, this was always a bit a best effort. to avoid having access to a session
and to speed up the archive. a better approximation would be to make repo paths
of the filenames before applying the path mapping.
> Package import fails for namespaced paths and path mapping
> --
>
> Key: JCRVLT-582
> URL: https://issues.apache.org/jira/browse/JCRVLT-582
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.5.8
>Reporter: Jean-Christophe Kautzmann
>Priority: Major
> Attachments: sites-3957.log
>
>
> Package import fails to import nodes when used as follows:
> * the package contains namespaced paths (e.g. {{/content/_cq_tags/src}})
> * regex path mapping are defined to map {{/content/cq:tags/src}} to
> {{/content/cq:tags/dest}}
> {code}
> RegexpPathMapping pathMapping = new RegexpPathMapping();
> for (String path : sitePaths.keySet()) {
> pathMapping.addMapping(path + "(/.*)?", sitePaths.get(path) + "$1");
> }
> ImportOptions options = new ImportOptions();
> options.setPathMapping(pathMapping);
> jcrPackage.install(options);
> {code}
> Result: nodes below {{/content/cq:tags}} are not created.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (JCRVLT-560) Clarify binary properties in FileVault DocView
[ https://issues.apache.org/jira/browse/JCRVLT-560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17417316#comment-17417316 ] Tobias Bocanegra commented on JCRVLT-560: - I don't think that binary values are serializable inline in DocView. we should clarify that in the documentation. > Clarify binary properties in FileVault DocView > -- > > Key: JCRVLT-560 > URL: https://issues.apache.org/jira/browse/JCRVLT-560 > Project: Jackrabbit FileVault > Issue Type: Bug >Reporter: Konrad Windszus >Priority: Major > Fix For: 3.5.4 > > > In contrast to JCR 2.0 DocView which states > bq. If P is a BINARY property its value is Base64 encoded. The resulting > string becomes the value of the XML attribute P. > (https://docs.adobe.com/content/docs/en/spec/jcr/2.0/7_Export.html#7.3%20Document%20View) > the binary support in FileVault DocView uses the default conversion from > String to UTF-8 byte array encoding for multi-value properties in > https://github.com/apache/jackrabbit-filevault/blob/b8627b9548ff1335cc0e497797b701a02a966654/vault-core/src/main/java/org/apache/jackrabbit/vault/util/DocViewProperty.java#L500 > > (https://docs.adobe.com/content/docs/en/spec/jcr/2.0/3_Repository_Model.html#3.6.4.1%20From%20STRING%20To) > or only binary references for single values: > https://github.com/apache/jackrabbit-filevault/blob/b8627b9548ff1335cc0e497797b701a02a966654/vault-core/src/main/java/org/apache/jackrabbit/vault/util/DocViewProperty.java#L519. > This difference is currently not explained in > https://jackrabbit.apache.org/filevault/docview.html and the handling is > inconsistent between single- and multi-value. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCRVLT-522) rep:policy and rep:repoPolicy applied even if filter rules exclude them
[ https://issues.apache.org/jira/browse/JCRVLT-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17405749#comment-17405749 ] Tobias Bocanegra commented on JCRVLT-522: - I think documenting is fine. thanks for point out. > rep:policy and rep:repoPolicy applied even if filter rules exclude them > --- > > Key: JCRVLT-522 > URL: https://issues.apache.org/jira/browse/JCRVLT-522 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: Packaging >Affects Versions: 3.4.10 >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: 3.5.4 > > > Currently the filter rules are not evaluated prior to applying ACLs (in > rep:policy and rep:repoPolicy files). According to JCRVLT-372 this is a bug. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCRVLT-549) node cannot be deleted if it's a multi-mandatory child node
[
https://issues.apache.org/jira/browse/JCRVLT-549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400968#comment-17400968
]
Tobias Bocanegra commented on JCRVLT-549:
-
the problem is, that {{cq:LiveSyncAction}} are mandatory child nodes, but with
the {{*}} names, i.e. you can actually delete them when at least 1 remains.
but the check in the import just rejects mandatory child nodes in general. it
would probably be better to check if it has a fix mandatory name.
> node cannot be deleted if it's a multi-mandatory child node
> ---
>
> Key: JCRVLT-549
> URL: https://issues.apache.org/jira/browse/JCRVLT-549
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Affects Versions: 3.4.0
>Reporter: Ankita Agarwal
>Priority: Major
>
> Let say we have a rule in nodetype.cnd file
> {code:xml}
> [a:RolloutConfig] > mix:title
> orderable
> - a:trigger (string) mandatory
> + * (a:LiveSyncAction) mandatory
> [a:LiveSyncAction] > nt:unstructured
> {code}
> When a package(first) is installed where parent node's(rolloutconfigs)
> .content.xml has:
> {code:xml}
>
> http://sling.apache.org/jcr/sling/1.0;
> xmlns:jcr="http://www.jcp.org/jcr/1.0; xmlns:rep="internal"
> jcr:mixinTypes="[rep:AccessControllable]"
> jcr:primaryType="sling:OrderedFolder"
> jcr:title="Rollout Configurations">
>
>
>
>
>
> {code}
> and default node's has .content.xml
> {code:xml}
>
> http://www.day.com/jcr/a/1.0;
> xmlns:jcr="http://www.jcp.org/jcr/1.0;
> a:trigger="rollout"
> jcr:description="abc"
> jcr:primaryType="a:RolloutConfig"
> jcr:title="Standard rollout config">
>
>
>
>
>
>
> {code}
> Installing another package(second) with the same cnd file but with different
> child node's(default node) content.xml:
> {code:xml}
>
> http://www.day.com/jcr/a/1.0;
> xmlns:jcr="http://www.jcp.org/jcr/1.0;
> a:trigger="rollout"
> jcr:description="abc"
> jcr:primaryType="a:RolloutConfig"
> jcr:title="Standard rollout config">
>
>
>
> {code}
> marks the below node for Deletion but doesn't delete them because it's a
> mandatory node
> {code:xml}
> D /x/y/z/rolloutconfigs/default/contentDelete
> D /x/y/z/rolloutconfigs/default/contentUpdate
> D /x/y/z/rolloutconfigs/default/orderChildren
> D /x/y/z/rolloutconfigs/default/personalizationContentRollout
> D /x/y/z/rolloutconfigs/default/referencesUpdate
> {code}
> The issue lies at
> https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.2.8/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/DocViewSAXImporter.java#L1190
> . Here, check for the child node is mandatory or not is done after marking
> it for delete importInfo.onDeleted(path) which gives wrong information that
> the child node is deleted but in the repository, it still exists.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (JCRVLT-549) node cannot be deleted if it's a multi-mandatory child node
[
https://issues.apache.org/jira/browse/JCRVLT-549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra updated JCRVLT-549:
Summary: node cannot be deleted if it's a multi-mandatory child node (was:
Mandatory node is not deleted but it's marked for deletion)
> node cannot be deleted if it's a multi-mandatory child node
> ---
>
> Key: JCRVLT-549
> URL: https://issues.apache.org/jira/browse/JCRVLT-549
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Affects Versions: 3.4.0
>Reporter: Ankita Agarwal
>Priority: Major
>
> Let say we have a rule in nodetype.cnd file
> {code:xml}
> [a:RolloutConfig] > mix:title
> orderable
> - a:trigger (string) mandatory
> + * (a:LiveSyncAction) mandatory
> [a:LiveSyncAction] > nt:unstructured
> {code}
> When a package(first) is installed where parent node's(rolloutconfigs)
> .content.xml has:
> {code:xml}
>
> http://sling.apache.org/jcr/sling/1.0;
> xmlns:jcr="http://www.jcp.org/jcr/1.0; xmlns:rep="internal"
> jcr:mixinTypes="[rep:AccessControllable]"
> jcr:primaryType="sling:OrderedFolder"
> jcr:title="Rollout Configurations">
>
>
>
>
>
> {code}
> and default node's has .content.xml
> {code:xml}
>
> http://www.day.com/jcr/a/1.0;
> xmlns:jcr="http://www.jcp.org/jcr/1.0;
> a:trigger="rollout"
> jcr:description="abc"
> jcr:primaryType="a:RolloutConfig"
> jcr:title="Standard rollout config">
>
>
>
>
>
>
> {code}
> Installing another package(second) with the same cnd file but with different
> child node's(default node) content.xml:
> {code:xml}
>
> http://www.day.com/jcr/a/1.0;
> xmlns:jcr="http://www.jcp.org/jcr/1.0;
> a:trigger="rollout"
> jcr:description="abc"
> jcr:primaryType="a:RolloutConfig"
> jcr:title="Standard rollout config">
>
>
>
> {code}
> marks the below node for Deletion but doesn't delete them because it's a
> mandatory node
> {code:xml}
> D /x/y/z/rolloutconfigs/default/contentDelete
> D /x/y/z/rolloutconfigs/default/contentUpdate
> D /x/y/z/rolloutconfigs/default/orderChildren
> D /x/y/z/rolloutconfigs/default/personalizationContentRollout
> D /x/y/z/rolloutconfigs/default/referencesUpdate
> {code}
> The issue lies at
> https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.2.8/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/DocViewSAXImporter.java#L1190
> . Here, check for the child node is mandatory or not is done after marking
> it for delete importInfo.onDeleted(path) which gives wrong information that
> the child node is deleted but in the repository, it still exists.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-551) Set jcr:uuid to value from package when overwriting referenceable node
[
https://issues.apache.org/jira/browse/JCRVLT-551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400555#comment-17400555
]
Tobias Bocanegra commented on JCRVLT-551:
-
I'm not sure anymore. afaicr, in jackrabbit, the referencers were stored with
the referenceable node. i.e. double-linking.
i'm not sure if oak just does a search, when you try to get all referencers.
[~mreutegg] might know the details.
> Set jcr:uuid to value from package when overwriting referenceable node
> --
>
> Key: JCRVLT-551
> URL: https://issues.apache.org/jira/browse/JCRVLT-551
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: vlt
>Affects Versions: 3.5.0
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently the code at
> https://github.com/apache/jackrabbit-filevault/blob/ac74458a0226eb503d96cf2b238cec78b6f36dc2/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/DocViewSAXImporter.java#L809
> does not try to adjust the {{jcr:uuid}} property in case a referenceable
> node is imported from a package which already exists with a different
> {{jcr:uuid}} in the repository.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-546) Remove private references from exported classes
[
https://issues.apache.org/jira/browse/JCRVLT-546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17375433#comment-17375433
]
Tobias Bocanegra commented on JCRVLT-546:
-
initially the idea was that a client can _mount_ the FS and then operate on it.
but I don't think that was ever used, so we can make it bundle private.
> Remove private references from exported classes
> ---
>
> Key: JCRVLT-546
> URL: https://issues.apache.org/jira/browse/JCRVLT-546
> Project: Jackrabbit FileVault
> Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.5.2
>
>
> The following issues are reported by Bnd:
> # {{[ERROR] .../vault-core/bnd.bnd [0:0]: Export
> org.apache.jackrabbit.vault.fs, has 1, private references
> [org.apache.jackrabbit.vault.fs.impl]}}: This is caused by some public
> classes extending {{org.apache.jackrabbit.vault.fs.impl.AbstractArtifact}}
> like {{DirectoryArtifact}} and others.
> # {{[ERROR] .../vault-core/bnd.bnd [0:0]: Export
> org.apache.jackrabbit.vault.fs.api, has 1, private references
> [org.apache.jackrabbit.spi2dav]}}: This is caused by {{RepositoryFactory}}
> using {{org.apache.jackrabbit.spi2dav.ConnectionOptions}} in method
> {{createRepository}}
> # {{[ERROR] .../vault-core/bnd.bnd [0:0]: Export
> org.apache.jackrabbit.vault.packaging, has 1, private references
> [org.apache.jackrabbit.vault.packaging.registry.impl]}}: This is caused by
> {{Packaging}} returning {{JcrPackageRegistry}} in
> {{getJcrPackageRegistry(...)}}.
> # {{[ERROR] .../vault-core/bnd.bnd [0:0]: Export
> org.apache.jackrabbit.vault.util, has 1, private references
> [org.apache.jackrabbit.spi2dav]}}: This is caused by {{RepositoryProvider}}
> using {{org.apache.jackrabbit.spi2dav.ConnectionOptions}} in method
> {{createRepository}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-546) Remove private references from exported classes
[
https://issues.apache.org/jira/browse/JCRVLT-546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17375415#comment-17375415
]
Tobias Bocanegra commented on JCRVLT-546:
-
usually, everything in impl.* is not public api.
> Remove private references from exported classes
> ---
>
> Key: JCRVLT-546
> URL: https://issues.apache.org/jira/browse/JCRVLT-546
> Project: Jackrabbit FileVault
> Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.5.2
>
>
> The following issues are reported by Bnd:
> # {{[ERROR] .../vault-core/bnd.bnd [0:0]: Export
> org.apache.jackrabbit.vault.fs, has 1, private references
> [org.apache.jackrabbit.vault.fs.impl]}}: This is caused by some public
> classes extending {{org.apache.jackrabbit.vault.fs.impl.AbstractArtifact}}
> like {{DirectoryArtifact}} and others.
> # {{[ERROR] .../vault-core/bnd.bnd [0:0]: Export
> org.apache.jackrabbit.vault.fs.api, has 1, private references
> [org.apache.jackrabbit.spi2dav]}}: This is caused by {{RepositoryFactory}}
> using {{org.apache.jackrabbit.spi2dav.ConnectionOptions}} in method
> {{createRepository}}
> # {{[ERROR] .../vault-core/bnd.bnd [0:0]: Export
> org.apache.jackrabbit.vault.packaging, has 1, private references
> [org.apache.jackrabbit.vault.packaging.registry.impl]}}: This is caused by
> {{Packaging}} returning {{JcrPackageRegistry}} in
> {{getJcrPackageRegistry(...)}}.
> # {{[ERROR] .../vault-core/bnd.bnd [0:0]: Export
> org.apache.jackrabbit.vault.util, has 1, private references
> [org.apache.jackrabbit.spi2dav]}}: This is caused by {{RepositoryProvider}}
> using {{org.apache.jackrabbit.spi2dav.ConnectionOptions}} in method
> {{createRepository}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-509) Make DocView import failures fail the whole installation
[
https://issues.apache.org/jira/browse/JCRVLT-509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17299221#comment-17299221
]
Tobias Bocanegra commented on JCRVLT-509:
-
well, it's a major change of behaviour. so I frankly don't know.
[~dsuess] wdyt ?
> Make DocView import failures fail the whole installation
>
>
> Key: JCRVLT-509
> URL: https://issues.apache.org/jira/browse/JCRVLT-509
> Project: Jackrabbit FileVault
> Issue Type: Improvement
>Affects Versions: 3.4.10
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 3.4.12
>
>
> Currently all ACL, authorizable and regular node exceptions are caught in
> https://github.com/apache/jackrabbit-filevault/blob/f91c3d73ab33e4155837768d70b7c3e8c7da9e2d/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/DocViewSAXImporter.java#L683
> and just logged. Afterwards the import of the package just continues. Only
> in case the ImportOptions.setStrict() is set to {{true}} it will lead to a
> PackageException in the end.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-509) Make DocView import failures fail the whole installation
[
https://issues.apache.org/jira/browse/JCRVLT-509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17298462#comment-17298462
]
Tobias Bocanegra commented on JCRVLT-509:
-
we always tried to import a package best effort.
> Make DocView import failures fail the whole installation
>
>
> Key: JCRVLT-509
> URL: https://issues.apache.org/jira/browse/JCRVLT-509
> Project: Jackrabbit FileVault
> Issue Type: Improvement
>Affects Versions: 3.4.10
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 3.4.12
>
>
> Currently all ACL, authorizable and regular node exceptions are caught in
> https://github.com/apache/jackrabbit-filevault/blob/f91c3d73ab33e4155837768d70b7c3e8c7da9e2d/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/DocViewSAXImporter.java#L683
> and just logged. Afterwards the import of the package just continues. Only
> in case the ImportOptions.setStrict() is set to {{true}} it will lead to a
> PackageException in the end.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-506) Remove o.a.j.v.fs.impl.io.CNDImporter and CDNSerializer
[ https://issues.apache.org/jira/browse/JCRVLT-506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17290551#comment-17290551 ] Tobias Bocanegra commented on JCRVLT-506: - I can't remember. either weren't the JR classes available yet, at the time we needed it or they do something different. I'd say, if you use the JR classes, and everything still works, we can drop the own ones. > Remove o.a.j.v.fs.impl.io.CNDImporter and CDNSerializer > --- > > Key: JCRVLT-506 > URL: https://issues.apache.org/jira/browse/JCRVLT-506 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: vlt >Reporter: Konrad Windszus >Priority: Major > Fix For: 3.4.10 > > > Both classes have no test coverage and Jackrabbit provides > http://jackrabbit.apache.org/api/2.20/org/apache/jackrabbit/commons/cnd/CndImporter.html > and > http://jackrabbit.apache.org/api/2.20/org/apache/jackrabbit/commons/cnd/CompactNodeTypeDefWriter.html > which can be used instead. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCRVLT-485) Validation fails for nodetypes extending mix:versionable
[
https://issues.apache.org/jira/browse/JCRVLT-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17242861#comment-17242861
]
Tobias Bocanegra commented on JCRVLT-485:
-
I would ignore the properties form mix:versionable, since the handling of
versions is done specially in filevault. Also note, that most of them have no
meaning for import, since we cannot recreate the same version history.
> Validation fails for nodetypes extending mix:versionable
>
>
> Key: JCRVLT-485
> URL: https://issues.apache.org/jira/browse/JCRVLT-485
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Affects Versions: 3.4.8
>Reporter: Stefan Seifert
>Priority: Major
> Fix For: 3.4.8
>
>
> when validation a content package containing data with a node type extending
> mix:versionable (and the protected properties are stripped out of the local
> content) validation failes with:
> {noformat}
> ERROR] ValidationViolation: "jackrabbit-nodetypes: Mandatory property
> 'jcr:predecessors' missing in node with types [cq:WorkflowModel] at
> /var/workflow/models/dam/dam_update_asset1"
> [ERROR] ValidationViolation: "jackrabbit-nodetypes: Mandatory property
> 'jcr:baseVersion' missing in node with types [cq:WorkflowModel] at
> /var/workflow/models/dam/dam_update_asset1"
> [ERROR] ValidationViolation: "jackrabbit-nodetypes: Mandatory property
> 'jcr:versionHistory' missing in node with types [cq:WorkflowModel] at
> /var/workflow/models/dam/dam_update_asset1"
> {noformat}
> sample project to reproduce the problem:
> https://github.com/stefanseifert/filevault-package-maven-plugin-validation-issues/tree/master/content-packages/workflow-content
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-472) Content package with principal policy fails to install when the user is in the same package
[
https://issues.apache.org/jira/browse/JCRVLT-472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17185540#comment-17185540
]
Tobias Bocanegra commented on JCRVLT-472:
-
so far we relied on the best-effort for all authorizable issues and it worked
just find. I wouldn't want to complicate the entire imported for this edge case.
especially, since there is a valid workaround.
> Content package with principal policy fails to install when the user is in
> the same package
> ---
>
> Key: JCRVLT-472
> URL: https://issues.apache.org/jira/browse/JCRVLT-472
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: Packaging
>Reporter: Robert Munteanu
>Priority: Major
> Attachments: sling-slingshot-apps-pkg-1.0-SNAPSHOT.zip
>
>
> I have attached a content package that includes a system user, a principal
> policy and a principal entry. The content package, when installed in the
> Sling Starter 12-SNAPSHOT, fails the first time and then the second time
> works. The full error is
> {noformat}24.08.2020 17:24:08.669 *WARN* [pool-10-thread-1]
> com.composum.sling.core.pckgmgr.util.PackageUtil Received error for mode
> PATHS path /home/users/system/sling/slingshot/rep:principalPolicy
> org.xml.sax.SAXException: javax.jcr.security.AccessControlException:
> Unsupported principal slingshot-service
> at
> org.apache.jackrabbit.vault.fs.impl.io.DocViewSAXImporter.endElement(DocViewSAXImporter.java:1246)
> [org.apache.jackrabbit.vault:3.4.6]
> at
> java.xml/com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:610)
> at
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1718)
> at
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2883)
> at
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:605)
> at
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:112)
> at
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:534)
> at
> java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:888)
> at
> java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:824)
> at
> java.xml/com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
> at
> java.xml/com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1216)
> at
> java.xml/com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:635)
> at
> java.xml/com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.parse(SAXParserImpl.java:324)
> at
> org.apache.jackrabbit.vault.fs.impl.io.GenericArtifactHandler.accept(GenericArtifactHandler.java:100)
> [org.apache.jackrabbit.vault:3.4.6]
> at
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:896)
> [org.apache.jackrabbit.vault:3.4.6]
> at
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:799)
> [org.apache.jackrabbit.vault:3.4.6]
> at
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839)
> [org.apache.jackrabbit.vault:3.4.6]
> at
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839)
> [org.apache.jackrabbit.vault:3.4.6]
> at
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839)
> [org.apache.jackrabbit.vault:3.4.6]
> at
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839)
> [org.apache.jackrabbit.vault:3.4.6]
> at
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839)
> [org.apache.jackrabbit.vault:3.4.6]
> at
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839)
> [org.apache.jackrabbit.vault:3.4.6]
> at org.apache.jackrabbit.vault.fs.io.Importer.run(Importer.java:440)
> [org.apache.jackrabbit.vault:3.4.6]
> at
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.extract(ZipVaultPackage.java:255)
> [org.apache.jackrabbit.vault:3.4.6]
> at
> org.apache.jackrabbit.vault.packaging.impl.JcrPackageImpl.extract(JcrPackageImpl.java:400)
> [org.apache.jackrabbit.vault:3.4.6]
> at
> org.apache.jackrabbit.vault.packaging.impl.JcrPackageImpl.extract(JcrPackageImpl.java:359)
> [org.apache.jackrabbit.vault:3.4.6]
>
[jira] [Commented] (JCRVLT-472) Content package with principal policy fails to install when the user is in the same package
[
https://issues.apache.org/jira/browse/JCRVLT-472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17184810#comment-17184810
]
Tobias Bocanegra commented on JCRVLT-472:
-
I think the best alternative would be to create 3 packages:
- a package with the principal (A)
- a package with the content using the principal (B), having a dependency on
package (A)
- a container package (C) that contains the packages A and B.
> Content package with principal policy fails to install when the user is in
> the same package
> ---
>
> Key: JCRVLT-472
> URL: https://issues.apache.org/jira/browse/JCRVLT-472
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: Packaging
>Reporter: Robert Munteanu
>Priority: Major
> Attachments: sling-slingshot-apps-pkg-1.0-SNAPSHOT.zip
>
>
> I have attached a content package that includes a system user, a principal
> policy and a principal entry. The content package, when installed in the
> Sling Starter 12-SNAPSHOT, fails the first time and then the second time
> works. The full error is
> {noformat}24.08.2020 17:24:08.669 *WARN* [pool-10-thread-1]
> com.composum.sling.core.pckgmgr.util.PackageUtil Received error for mode
> PATHS path /home/users/system/sling/slingshot/rep:principalPolicy
> org.xml.sax.SAXException: javax.jcr.security.AccessControlException:
> Unsupported principal slingshot-service
> at
> org.apache.jackrabbit.vault.fs.impl.io.DocViewSAXImporter.endElement(DocViewSAXImporter.java:1246)
> [org.apache.jackrabbit.vault:3.4.6]
> at
> java.xml/com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:610)
> at
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1718)
> at
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2883)
> at
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:605)
> at
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:112)
> at
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:534)
> at
> java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:888)
> at
> java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:824)
> at
> java.xml/com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
> at
> java.xml/com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1216)
> at
> java.xml/com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:635)
> at
> java.xml/com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.parse(SAXParserImpl.java:324)
> at
> org.apache.jackrabbit.vault.fs.impl.io.GenericArtifactHandler.accept(GenericArtifactHandler.java:100)
> [org.apache.jackrabbit.vault:3.4.6]
> at
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:896)
> [org.apache.jackrabbit.vault:3.4.6]
> at
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:799)
> [org.apache.jackrabbit.vault:3.4.6]
> at
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839)
> [org.apache.jackrabbit.vault:3.4.6]
> at
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839)
> [org.apache.jackrabbit.vault:3.4.6]
> at
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839)
> [org.apache.jackrabbit.vault:3.4.6]
> at
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839)
> [org.apache.jackrabbit.vault:3.4.6]
> at
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839)
> [org.apache.jackrabbit.vault:3.4.6]
> at
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839)
> [org.apache.jackrabbit.vault:3.4.6]
> at org.apache.jackrabbit.vault.fs.io.Importer.run(Importer.java:440)
> [org.apache.jackrabbit.vault:3.4.6]
> at
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.extract(ZipVaultPackage.java:255)
> [org.apache.jackrabbit.vault:3.4.6]
> at
> org.apache.jackrabbit.vault.packaging.impl.JcrPackageImpl.extract(JcrPackageImpl.java:400)
> [org.apache.jackrabbit.vault:3.4.6]
> at
> org.apache.jackrabbit.vault.packaging.impl.JcrPackageImpl.extract(JcrPackageImpl.java:359)
>
[jira] [Commented] (JCRVLT-472) Content package with principal policy fails to install when the user is in the same package
[
https://issues.apache.org/jira/browse/JCRVLT-472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17183828#comment-17183828
]
Tobias Bocanegra commented on JCRVLT-472:
-
thanks [~angela]. I totally forgot that `isNodeType()` is inheritance aware.
> Content package with principal policy fails to install when the user is in
> the same package
> ---
>
> Key: JCRVLT-472
> URL: https://issues.apache.org/jira/browse/JCRVLT-472
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: Packaging
>Reporter: Robert Munteanu
>Priority: Major
> Attachments: sling-slingshot-apps-pkg-1.0-SNAPSHOT.zip
>
>
> I have attached a content package that includes a system user, a principal
> policy and a principal entry. The content package, when installed in the
> Sling Starter 12-SNAPSHOT, fails the first time and then the second time
> works. The full error is
> {noformat}24.08.2020 17:24:08.669 *WARN* [pool-10-thread-1]
> com.composum.sling.core.pckgmgr.util.PackageUtil Received error for mode
> PATHS path /home/users/system/sling/slingshot/rep:principalPolicy
> org.xml.sax.SAXException: javax.jcr.security.AccessControlException:
> Unsupported principal slingshot-service
> at
> org.apache.jackrabbit.vault.fs.impl.io.DocViewSAXImporter.endElement(DocViewSAXImporter.java:1246)
> [org.apache.jackrabbit.vault:3.4.6]
> at
> java.xml/com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:610)
> at
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1718)
> at
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2883)
> at
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:605)
> at
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:112)
> at
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:534)
> at
> java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:888)
> at
> java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:824)
> at
> java.xml/com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
> at
> java.xml/com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1216)
> at
> java.xml/com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:635)
> at
> java.xml/com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.parse(SAXParserImpl.java:324)
> at
> org.apache.jackrabbit.vault.fs.impl.io.GenericArtifactHandler.accept(GenericArtifactHandler.java:100)
> [org.apache.jackrabbit.vault:3.4.6]
> at
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:896)
> [org.apache.jackrabbit.vault:3.4.6]
> at
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:799)
> [org.apache.jackrabbit.vault:3.4.6]
> at
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839)
> [org.apache.jackrabbit.vault:3.4.6]
> at
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839)
> [org.apache.jackrabbit.vault:3.4.6]
> at
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839)
> [org.apache.jackrabbit.vault:3.4.6]
> at
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839)
> [org.apache.jackrabbit.vault:3.4.6]
> at
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839)
> [org.apache.jackrabbit.vault:3.4.6]
> at
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839)
> [org.apache.jackrabbit.vault:3.4.6]
> at org.apache.jackrabbit.vault.fs.io.Importer.run(Importer.java:440)
> [org.apache.jackrabbit.vault:3.4.6]
> at
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.extract(ZipVaultPackage.java:255)
> [org.apache.jackrabbit.vault:3.4.6]
> at
> org.apache.jackrabbit.vault.packaging.impl.JcrPackageImpl.extract(JcrPackageImpl.java:400)
> [org.apache.jackrabbit.vault:3.4.6]
> at
> org.apache.jackrabbit.vault.packaging.impl.JcrPackageImpl.extract(JcrPackageImpl.java:359)
> [org.apache.jackrabbit.vault:3.4.6]
> at
> org.apache.jackrabbit.vault.packaging.impl.JcrPackageImpl.install(JcrPackageImpl.java:353)
>
[jira] [Commented] (JCRVLT-472) Content package with principal policy fails to install when the user is in the same package
[
https://issues.apache.org/jira/browse/JCRVLT-472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17183716#comment-17183716
]
Tobias Bocanegra commented on JCRVLT-472:
-
I think the {{rep:principalPolicy}} is new and isn't handled in the
ACLManagement yet:
https://github.com/apache/jackrabbit-filevault/blob/0b3c4cb5a99d14e3d0ae881d7864806ed950c622/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/spi/impl/jcr20/JcrACLManagement.java#L53
> Content package with principal policy fails to install when the user is in
> the same package
> ---
>
> Key: JCRVLT-472
> URL: https://issues.apache.org/jira/browse/JCRVLT-472
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: Packaging
>Reporter: Robert Munteanu
>Priority: Major
> Attachments: sling-slingshot-apps-pkg-1.0-SNAPSHOT.zip
>
>
> I have attached a content package that includes a system user, a principal
> policy and a principal entry. The content package, when installed in the
> Sling Starter 12-SNAPSHOT, fails the first time and then the second time
> works. The full error is
> {noformat}24.08.2020 17:24:08.669 *WARN* [pool-10-thread-1]
> com.composum.sling.core.pckgmgr.util.PackageUtil Received error for mode
> PATHS path /home/users/system/sling/slingshot/rep:principalPolicy
> org.xml.sax.SAXException: javax.jcr.security.AccessControlException:
> Unsupported principal slingshot-service
> at
> org.apache.jackrabbit.vault.fs.impl.io.DocViewSAXImporter.endElement(DocViewSAXImporter.java:1246)
> [org.apache.jackrabbit.vault:3.4.6]
> at
> java.xml/com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:610)
> at
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1718)
> at
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2883)
> at
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:605)
> at
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:112)
> at
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:534)
> at
> java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:888)
> at
> java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:824)
> at
> java.xml/com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
> at
> java.xml/com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1216)
> at
> java.xml/com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:635)
> at
> java.xml/com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.parse(SAXParserImpl.java:324)
> at
> org.apache.jackrabbit.vault.fs.impl.io.GenericArtifactHandler.accept(GenericArtifactHandler.java:100)
> [org.apache.jackrabbit.vault:3.4.6]
> at
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:896)
> [org.apache.jackrabbit.vault:3.4.6]
> at
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:799)
> [org.apache.jackrabbit.vault:3.4.6]
> at
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839)
> [org.apache.jackrabbit.vault:3.4.6]
> at
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839)
> [org.apache.jackrabbit.vault:3.4.6]
> at
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839)
> [org.apache.jackrabbit.vault:3.4.6]
> at
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839)
> [org.apache.jackrabbit.vault:3.4.6]
> at
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839)
> [org.apache.jackrabbit.vault:3.4.6]
> at
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:839)
> [org.apache.jackrabbit.vault:3.4.6]
> at org.apache.jackrabbit.vault.fs.io.Importer.run(Importer.java:440)
> [org.apache.jackrabbit.vault:3.4.6]
> at
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.extract(ZipVaultPackage.java:255)
> [org.apache.jackrabbit.vault:3.4.6]
> at
> org.apache.jackrabbit.vault.packaging.impl.JcrPackageImpl.extract(JcrPackageImpl.java:400)
> [org.apache.jackrabbit.vault:3.4.6]
> at
>
[jira] [Created] (JCRVLT-458) DependencyUtil.sortPackages() and DependencyUtil.resolve() very expensive
Tobias Bocanegra created JCRVLT-458:
---
Summary: DependencyUtil.sortPackages() and
DependencyUtil.resolve() very expensive
Key: JCRVLT-458
URL: https://issues.apache.org/jira/browse/JCRVLT-458
Project: Jackrabbit FileVault
Issue Type: Bug
Components: Packaging
Affects Versions: 3.4.4
Reporter: Tobias Bocanegra
Fix For: 3.4.6
The algorithm to resolve the package dependencies in
{{DependencyUtil.resolve()}} is very inefficient and can cause high CPU load
and unresponsiveness, of the dependency tree is deep and/or has a lot of
unresolvable packages.
The {{DependencyUtil.sortPackages()}} uses the {{DependencyUtil.resolve()}} in
order to sort them in the resolution order.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-447) Add AbstractExporter implementation to export a single node
[ https://issues.apache.org/jira/browse/JCRVLT-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17150732#comment-17150732 ] Tobias Bocanegra commented on JCRVLT-447: - but then the approach above is not complete... it only covers the edge case, where 1 node is reflected as 1 file. but it doesn't cover the more complex structures, like a dam asset. also it doesn't address the import at all. btw: I worked with the repo too quite a bit, and I never thought that it is too slow > Add AbstractExporter implementation to export a single node > --- > > Key: JCRVLT-447 > URL: https://issues.apache.org/jira/browse/JCRVLT-447 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: Misc >Reporter: Manfred Baedke >Priority: Minor > > Sometimes it may be convenient to not export a full package, but only the > system view of the requested node. I propose adding a suitable > AbstractExporter implementation as linked below. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCRVLT-447) Add AbstractExporter implementation to export a single node
[ https://issues.apache.org/jira/browse/JCRVLT-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17150635#comment-17150635 ] Tobias Bocanegra commented on JCRVLT-447: - I still don't see why this would help. the vault serialization depends on the context, so a single node might be exported as single docview (.content.xml) or as a directory or as a binary file or as a full coverage aggregate. there are plenty of tools that allow for quick synchronization that even take into account the proper workspace filters. eg:https://github.com/Adobe-Marketing-Cloud/tools/tree/master/repo#repo---ftp-like-tool-for-jcr-content I just don't what to add a feature to the API that as IMO no value and can be solved differently. > Add AbstractExporter implementation to export a single node > --- > > Key: JCRVLT-447 > URL: https://issues.apache.org/jira/browse/JCRVLT-447 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: Misc >Reporter: Manfred Baedke >Priority: Minor > > Sometimes it may be convenient to not export a full package, but only the > system view of the requested node. I propose adding a suitable > AbstractExporter implementation as linked below. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCRVLT-447) Add AbstractExporter implementation to export a single node
[ https://issues.apache.org/jira/browse/JCRVLT-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148241#comment-17148241 ] Tobias Bocanegra commented on JCRVLT-447: - I mean: the feature of exporting 1 node this way is very project specific and I would want to change the API just for that. If all you want is a doc view serializaiton of 1 node, there are many other ways on how to do it. After all, that's what JCRFS was built for :-) I'm not able to try it out myself right now, but your code from the patch might look like a solution you could add to your project. > Add AbstractExporter implementation to export a single node > --- > > Key: JCRVLT-447 > URL: https://issues.apache.org/jira/browse/JCRVLT-447 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: Misc >Reporter: Manfred Baedke >Priority: Minor > > Sometimes it may be convenient to not export a full package, but only the > system view of the requested node. I propose adding a suitable > AbstractExporter implementation as linked below. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCRVLT-449) VLT-RCP: Optionally persist tasks
[ https://issues.apache.org/jira/browse/JCRVLT-449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17147487#comment-17147487 ] Tobias Bocanegra commented on JCRVLT-449: - the rcp tasks are only used during migration and require admin access. currently the RCP servlet is not secured, which allows everyone to install tasks. being able to install the tasks via packages makes it probably even more insecure. I would - require an admin session when adding a task - store the tasks in the bundle data - ensure that the entire task state is stored (e.g. copy traversal state) > VLT-RCP: Optionally persist tasks > - > > Key: JCRVLT-449 > URL: https://issues.apache.org/jira/browse/JCRVLT-449 > Project: Jackrabbit FileVault > Issue Type: Improvement >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: 3.4.6 > > > All tasks in the RcpTaskManagerImpl are only held in memory, which means they > will be gone after a service/bundle/system restart. It should be possible to > persist the tasks either in the repository or the bundle data file > (https://docs.osgi.org/javadoc/r4v43/core/org/osgi/framework/BundleContext.html#getDataFile(java.lang.String)) > to make them survive restarts. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCRVLT-450) Deprecate duplicate/unused util classes
[ https://issues.apache.org/jira/browse/JCRVLT-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17146793#comment-17146793 ] Tobias Bocanegra commented on JCRVLT-450: - deprecation ok, but not removal. I would avoid anything that changes the API version due to reduced backportability. Although, I don't expect that anyone was using those classes outside of filevault. > Deprecate duplicate/unused util classes > > > Key: JCRVLT-450 > URL: https://issues.apache.org/jira/browse/JCRVLT-450 > Project: Jackrabbit FileVault > Issue Type: Improvement >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Minor > Fix For: 3.4.6 > > > The following classes should be deprecated and their internal usage refactored > * > https://github.com/apache/jackrabbit-filevault/blob/master/vault-core/src/main/java/org/apache/jackrabbit/vault/util/Text.java > (instead use > https://github.com/apache/jackrabbit/blob/2.20/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/util/Text.java) > * > https://github.com/apache/jackrabbit-filevault/blob/master/vault-core/src/main/java/org/apache/jackrabbit/vault/util/SHA1.java > (unused inside FileVault) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCRVLT-447) Add AbstractExporter implementation to export a single node
[
https://issues.apache.org/jira/browse/JCRVLT-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17146002#comment-17146002
]
Tobias Bocanegra commented on JCRVLT-447:
-
hmm..if you only need the docview export of a node (without the binary
properties), you probably can do something like you suggest in your patch:
{noformat}
VaultFileSystem jcrfs = Mounter.mount(config, metaInf.getFilter(),
addr, opts.getRootPath(), s);
JarExporter exporter = new JarExporter(out, opts.getCompressionLevel());
AbstractExporter exporter = opts.isNodeOnly() ? new NodeExporter(out) :
new JarExporter(out, opts.getCompressionLevel());
exporter.setProperties(metaInf.getProperties());
if (opts.getListener() != null) {
exporter.setVerbose(opts.getListener());
}
if (opts.getPostProcessor() != null) {
exporter.export(jcrfs.getRoot(), true);
opts.getPostProcessor().process(exporter);
exporter.close();
} else {
exporter.export(jcrfs.getRoot());
}
jcrfs.unmount();
{noformat}
> Add AbstractExporter implementation to export a single node
> ---
>
> Key: JCRVLT-447
> URL: https://issues.apache.org/jira/browse/JCRVLT-447
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: Misc
>Reporter: Manfred Baedke
>Priority: Minor
>
> Sometimes it may be convenient to not export a full package, but only the
> system view of the requested node. I propose adding a suitable
> AbstractExporter implementation as linked below.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-448) JcrPackageManagerImpl.rewrap and assemble do not close passed output stream
[ https://issues.apache.org/jira/browse/JCRVLT-448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143433#comment-17143433 ] Tobias Bocanegra commented on JCRVLT-448: - yes, it does: https://github.com/apache/jackrabbit-filevault/blob/70dfb76e5c5aef46866b6e31570ce6cea9c9ccd7/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/io/AbstractExporter.java#L270 > JcrPackageManagerImpl.rewrap and assemble do not close passed output stream > --- > > Key: JCRVLT-448 > URL: https://issues.apache.org/jira/browse/JCRVLT-448 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Affects Versions: 3.4.4 >Reporter: Konrad Windszus >Priority: Critical > Fix For: 3.4.6 > > > Despite their javadoc saying otherwise both > https://github.com/apache/jackrabbit-filevault/blob/70dfb76e5c5aef46866b6e31570ce6cea9c9ccd7/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/impl/PackageManagerImpl.java#L205 > and > https://github.com/apache/jackrabbit-filevault/blob/70dfb76e5c5aef46866b6e31570ce6cea9c9ccd7/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/impl/PackageManagerImpl.java#L132 > do not(!) close the passed output stream. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCRVLT-447) Add AbstractExporter implementation to export a single node
[ https://issues.apache.org/jira/browse/JCRVLT-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143431#comment-17143431 ] Tobias Bocanegra commented on JCRVLT-447: - I do not really see the use case for this. the created package violates the contract in respect to the give filter. if you really only want to export 1 node, then just set the appropriate filter. > Add AbstractExporter implementation to export a single node > --- > > Key: JCRVLT-447 > URL: https://issues.apache.org/jira/browse/JCRVLT-447 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: Misc >Reporter: Manfred Baedke >Priority: Minor > > Sometimes it may be convenient to not export a full package, but only the > system view of the requested node. I propose adding a suitable > AbstractExporter implementation as linked below. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (JCRVLT-443) Allow dependencies in "container" package type
[
https://issues.apache.org/jira/browse/JCRVLT-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17138914#comment-17138914
]
Tobias Bocanegra edited comment on JCRVLT-443 at 6/18/20, 12:18 AM:
I think we added the import package requirements for bundles to the package,
but never implemented a validation check. since jackrabbit doesn't really know
about OSGi.
But I agree with [~dsuess] that we should not allow dependencies in container
packages.
We use to do this for a long time, and it got us in deep troubles when trying
to resolve the installation order of larger package sets.
was (Author: tripod):
I think we added the import package requirements for bundles to the package,
but never implemented a validation check. since jackrabbit doesn't really know
about OSGi.
> Allow dependencies in "container" package type
> --
>
> Key: JCRVLT-443
> URL: https://issues.apache.org/jira/browse/JCRVLT-443
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: Packaging
>Affects Versions: 3.4.4
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 3.4.6
>
>
> According to JCRVLT-170 {{container}} packages must not have package
> dependencies.
> Sometimes there are multiple container packages though and with the nesting
> of container packages added in JCRVLT-401 it makes sense now to add package
> dependencies also to containers (to enforce a certain order in case they are
> nested or just because at build time the dependency cannot be resolved, i.e.
> included in the container package)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-443) Allow dependencies in "container" package type
[
https://issues.apache.org/jira/browse/JCRVLT-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17138914#comment-17138914
]
Tobias Bocanegra commented on JCRVLT-443:
-
I think we added the import package requirements for bundles to the package,
but never implemented a validation check. since jackrabbit doesn't really know
about OSGi.
> Allow dependencies in "container" package type
> --
>
> Key: JCRVLT-443
> URL: https://issues.apache.org/jira/browse/JCRVLT-443
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: Packaging
>Affects Versions: 3.4.4
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 3.4.6
>
>
> According to JCRVLT-170 {{container}} packages must not have package
> dependencies.
> Sometimes there are multiple container packages though and with the nesting
> of container packages added in JCRVLT-401 it makes sense now to add package
> dependencies also to containers (to enforce a certain order in case they are
> nested or just because at build time the dependency cannot be resolved, i.e.
> included in the container package)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-440) Do not treat Throwables differently than PackageExceptions in Hooks
[
https://issues.apache.org/jira/browse/JCRVLT-440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17118172#comment-17118172
]
Tobias Bocanegra commented on JCRVLT-440:
-
I wouldn't want to change the API. feel free to return `false` for all
exceptions. but I would not throw them.
> Do not treat Throwables differently than PackageExceptions in Hooks
> ---
>
> Key: JCRVLT-440
> URL: https://issues.apache.org/jira/browse/JCRVLT-440
> Project: Jackrabbit FileVault
> Issue Type: Improvement
>Affects Versions: 3.4.4
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 3.4.6
>
>
> Currently only {{PackageExceptions}} in hooks leads to package installation
> failures. All {{Throwable}} s are basically silently ignored (with just a
> small warning) at
> https://github.com/apache/jackrabbit-filevault/blob/38ab44e815e114479dcf06dabfbfd5a1898a192f/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/impl/InstallHookProcessorImpl.java#L152.
> IMHO all exceptions should lead to package installation failures which are
> also propagated to the client.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-429) Switch to bnd-maven-plugin
[ https://issues.apache.org/jira/browse/JCRVLT-429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111947#comment-17111947 ] Tobias Bocanegra commented on JCRVLT-429: - AFAIRC, this library is never used as bundle. > Switch to bnd-maven-plugin > -- > > Key: JCRVLT-429 > URL: https://issues.apache.org/jira/browse/JCRVLT-429 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: vlt >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: 3.4.6 > > > We should switch to using the bnd maven plugins directly instead of using the > Felix wrapper. They have less overhead and are used since quite a while > successfully in Apache Sling now. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (JCRVLT-429) Switch to bnd-maven-plugin
[ https://issues.apache.org/jira/browse/JCRVLT-429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111947#comment-17111947 ] Tobias Bocanegra edited comment on JCRVLT-429 at 5/20/20, 8:56 AM: --- AFAIRC, this library is never used as bundle. it is only used in the command line tools. was (Author: tripod): AFAIRC, this library is never used as bundle. > Switch to bnd-maven-plugin > -- > > Key: JCRVLT-429 > URL: https://issues.apache.org/jira/browse/JCRVLT-429 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: vlt >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: 3.4.6 > > > We should switch to using the bnd maven plugins directly instead of using the > Felix wrapper. They have less overhead and are used since quite a while > successfully in Apache Sling now. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCRVLT-436) VLT-RCP bundle no longer working with older Jackrabbit/Oak versions
[ https://issues.apache.org/jira/browse/JCRVLT-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17106749#comment-17106749 ] Tobias Bocanegra commented on JCRVLT-436: - I don't think this was deliberate. IMO, the RCP bundle should not embed any jackrabbit/oak libraries, but expect those to be installed in AEM. > VLT-RCP bundle no longer working with older Jackrabbit/Oak versions > --- > > Key: JCRVLT-436 > URL: https://issues.apache.org/jira/browse/JCRVLT-436 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: RCP >Affects Versions: 3.4.4 >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: 3.4.6 > > Attachments: Screenshot 2020-05-13 at 16.28.08.png > > > Due to the upgrade of the dependencies in > https://issues.apache.org/jira/browse/JCRVLT-344 and > https://issues.apache.org/jira/browse/JCRVLT-399 the vlt-rcp bundle does no > longer start on older distributions. > E.g. on AEM 6.5.4 the following imports can no be resolved: > # org.apache.jackrabbit.util,version=[2.5.0,3) -- Cannot be resolved > (exported in older version by bundle > org.apache.jackrabbit.jackrabbit-jcr-commons) > # org.apache.jackrabbit.api.security,version=[2.4.1,2.5) -- Cannot be > resolved (exported in older version by bundle > org.apache.jackrabbit.jackrabbit-api) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (JCRVLT-419) Feature/enable insecure https host
[
https://issues.apache.org/jira/browse/JCRVLT-419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra reassigned JCRVLT-419:
---
Assignee: Tobias Bocanegra
> Feature/enable insecure https host
> --
>
> Key: JCRVLT-419
> URL: https://issues.apache.org/jira/browse/JCRVLT-419
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: vlt
>Reporter: Max Barrass
>Assignee: Tobias Bocanegra
>Priority: Major
>
> Provide insecure flag to enable access to https with expired certs.
> Adding a new cli argument {{--insecure}}.
> Enabling optional support for expired ssl certs when using https on
> development server with self generated certificates.
> There is a corresponding PR in the required jackrabbit dependency
> [apache/jackrabbit#88
> |https://github.com/apache/jackrabbit/pull/88]
> Pull request is read for review
> [https://github.com/apache/jackrabbit-filevault/pull/64]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-427) Allow installation of packages with hook for users without admin privileges
[ https://issues.apache.org/jira/browse/JCRVLT-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17089203#comment-17089203 ] Tobias Bocanegra commented on JCRVLT-427: - [~angela] thanks for your input. The hooks are arbitrary java code that is provided by the package and is executed during installation. Although they are running on the same session the user uses to install the package, they still can do nasty things like `system.exit()`. That's why filevault doesn't allow to install packages with hooks by non-admins. > Allow installation of packages with hook for users without admin privileges > --- > > Key: JCRVLT-427 > URL: https://issues.apache.org/jira/browse/JCRVLT-427 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: vlt >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: 3.4.6 > > > Currently due to the check in > https://github.com/apache/jackrabbit-filevault/blob/e257001ec22ea06bcc987cbf79f0cc9b15c4e186/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/impl/ZipVaultPackage.java#L184 > packages containing a hook can only be installed by admins. > Although I do understand the intent of that I think this is not flexible > enough as currently that only gives the rights to users "admin", "system" or > members of group "administrators". Instead there should be an OSGi > configuration which allows to configure to grant the right to install > packages with hooks to other groups as well! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCRVLT-427) Allow installation of packages with hook for users without admin privileges
[ https://issues.apache.org/jira/browse/JCRVLT-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17074180#comment-17074180 ] Tobias Bocanegra commented on JCRVLT-427: - [~angela] WDYT about the suggestion of [~henzlerg]? > Allow installation of packages with hook for users without admin privileges > --- > > Key: JCRVLT-427 > URL: https://issues.apache.org/jira/browse/JCRVLT-427 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: vlt >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: 3.4.6 > > > Currently due to the check in > https://github.com/apache/jackrabbit-filevault/blob/e257001ec22ea06bcc987cbf79f0cc9b15c4e186/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/impl/ZipVaultPackage.java#L184 > packages containing a hook can only be installed by admins. > Although I do understand the intent of that I think this is not flexible > enough as currently that only gives the rights to users "admin", "system" or > members of group "administrators". Instead there should be an OSGi > configuration which allows to configure to grant the right to install > packages with hooks to other groups as well! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCRVLT-427) Allow installation of packages with hook for users without admin privileges
[ https://issues.apache.org/jira/browse/JCRVLT-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17072305#comment-17072305 ] Tobias Bocanegra commented on JCRVLT-427: - +1, however I think that it should not be possible to remove the default settings, i.e. `system`, `admin` and `administrstors` should always be allowed to install a package. > Allow installation of packages with hook for users without admin privileges > --- > > Key: JCRVLT-427 > URL: https://issues.apache.org/jira/browse/JCRVLT-427 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: vlt >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: 3.4.6 > > > Currently due to the check in > https://github.com/apache/jackrabbit-filevault/blob/e257001ec22ea06bcc987cbf79f0cc9b15c4e186/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/impl/ZipVaultPackage.java#L184 > packages containing a hook can only be installed by admins. > Although I do understand the intent of that I think this is not flexible > enough as currently that only gives the rights to users "admin", "system" or > members of group "administrators". Instead there should be an OSGi > configuration which allows to configure to grant the right to install > packages with hooks to other groups as well! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCRVLT-423) filevault-package-maven-plugin 1.1.2: Validation fails on /content/cq:tags node
[
https://issues.apache.org/jira/browse/JCRVLT-423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17063711#comment-17063711
]
Tobias Bocanegra commented on JCRVLT-423:
-
we could add the most common namespaces, like cq,jcr,sling,oak as fallback for
such cases.
> filevault-package-maven-plugin 1.1.2: Validation fails on /content/cq:tags
> node
> ---
>
> Key: JCRVLT-423
> URL: https://issues.apache.org/jira/browse/JCRVLT-423
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.1.2
>Reporter: Stefan Seifert
>Priority: Major
>
> i've encountered another problem, occurs on 1.1.2 and 1.1.3-SNAPSHOT, not
> with version 1.1.0 of the plugin.
> sample project that contains some content below {{/content/cq:tags}}:
> https://github.com/stefanseifert/filevault-package-maven-plugin-1.1.2-validation-issues/tree/master/content-packages/sample-content
> leads to validation failures:
> {noformat}
> [ERROR] ValidationViolation: "jackrabbit-docviewparser: Invalid XML found:
> Given root node name 'cq:tags' (implicitly given via filename) cannot be
> resolved. The prefix used in the filename must be declared as XML namespace
> in the child docview XML as well!",
> filePath=jcr_root\content\_cq_tags\.content.xml
> [ERROR] ValidationViolation: "jackrabbit-filter: Node
> '/content/cq:tags/.content.xml' is not contained in any of the filter rules",
> filePath=jcr_root\content\_cq_tags\.content.xml
> {noformat}
> the package content is exactly that what the package manager produced when
> downloading the package, so the package data itself is correct.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-416) Adding a package dependency to a package containing it as subpackage leads to a dependency cycle
[
https://issues.apache.org/jira/browse/JCRVLT-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17049801#comment-17049801
]
Tobias Bocanegra commented on JCRVLT-416:
-
i see... yes :-)
> Adding a package dependency to a package containing it as subpackage leads to
> a dependency cycle
>
>
> Key: JCRVLT-416
> URL: https://issues.apache.org/jira/browse/JCRVLT-416
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.1.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: package-maven-plugin-1.1.2
>
>
> Consider the case where {{a}} is a subpackage of {{b}}. This requires {{a}}
> being a Maven dependency of Maven Module {{b}}. Since every package
> installation of {{b}} adds {{b}} as package dependency to {{a}} implicitly
> (compare with https://issues.apache.org/jira/browse/JCRVLT-140) it should
> also be possible to make this implicit dependency and explicit one (to make
> the validator be able to detect e.g. filter roots being provided by {{b}}).
> But once you also add {{a}} as dependency to {{b}} you get a dependency cycle.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-415) jackrabbit-emptyelements validator reports error for nested folders
[
https://issues.apache.org/jira/browse/JCRVLT-415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17049800#comment-17049800
]
Tobias Bocanegra commented on JCRVLT-415:
-
I think JCRVLT-251 is a different case. there the {{testchild}} is mentioned in
the parents {{.content.xml}}. but is not contained as directory in the package
(I guess).
so: {{nt:folder}} is only forced, if the package contains the directory
> jackrabbit-emptyelements validator reports error for nested folders
> ---
>
> Key: JCRVLT-415
> URL: https://issues.apache.org/jira/browse/JCRVLT-415
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Affects Versions: 3.4.2
>Reporter: Csaba Varga
>Priority: Minor
> Fix For: 3.4.4
>
> Attachments: test.zip, test2.zip
>
>
> When an nt:folder node is present under an orderable node, the
> "jackrabbit-emptyelements" validator will report an issue (breaking the build
> with the default settings of the package Maven plugin). I believe this
> shouldn't be reported as an issue because the AEM Package Manager can
> generate packages like this. For example, see the attached test.zip file,
> which was exported on an out-of-the-box AEM 6.5 instance with dummy nodes.
> To reproduce, save test.zip somewhere, then invoke the validation Maven goal
> in the command like like this:
> {{mvn org.apache.jackrabbit:filevault-package-maven-plugin:validate-package
> -Dvault.packageToValidate=test.zip}}
> test.zip contains the following very simple node hierarchy:
> {{/}}
> {{ test (nt:unstructured)}}
> {{ foo (nt:folder)}}
> {{ bar (nt:folder)}}
> {{ baz (sling:OrderedFolder)}}
> The error I'm getting is:
> {{[ERROR] ValidationViolation: "jackrabbit-emptyelements: Found empty nodes:
> '/test/foo' (in 'test\.content.xml') (used for ordering only) which are
> included in the filter with mode=merge. Rather use the according
> include/exclude patterns."}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-416) Adding a package dependency to a package containing it as subpackage leads to a dependency cycle
[
https://issues.apache.org/jira/browse/JCRVLT-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17047336#comment-17047336
]
Tobias Bocanegra commented on JCRVLT-416:
-
but still, you can install b w/o a. so a is not a dependency of b.
> Adding a package dependency to a package containing it as subpackage leads to
> a dependency cycle
>
>
> Key: JCRVLT-416
> URL: https://issues.apache.org/jira/browse/JCRVLT-416
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.1.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: package-maven-plugin-1.1.2
>
>
> Consider the case where {{a}} is a subpackage of {{b}}. This requires {{a}}
> being a Maven dependency of Maven Module {{b}}. Since every package
> installation of {{b}} adds {{b}} as package dependency to {{a}} implicitly
> (compare with https://issues.apache.org/jira/browse/JCRVLT-140) it should
> also be possible to make this implicit dependency and explicit one (to make
> the validator be able to detect e.g. filter roots being provided by {{b}}).
> But once you also add {{a}} as dependency to {{b}} you get a dependency cycle.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-416) Adding a package dependency to a package containing it as subpackage leads to a dependency cycle
[
https://issues.apache.org/jira/browse/JCRVLT-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17047314#comment-17047314
]
Tobias Bocanegra commented on JCRVLT-416:
-
bq. But once you also add a as dependency to b you get a dependency cycle.
why should a be a dependency of b ? it's the other way around.
you can install 'b' without 'a', but not vice versa.
> Adding a package dependency to a package containing it as subpackage leads to
> a dependency cycle
>
>
> Key: JCRVLT-416
> URL: https://issues.apache.org/jira/browse/JCRVLT-416
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.1.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: package-maven-plugin-1.1.2
>
>
> Consider the case where {{a}} is a subpackage of {{b}}. This requires {{a}}
> being a Maven dependency of Maven Module {{b}}. Since every package
> installation of {{b}} adds {{b}} as package dependency to {{a}} implicitly
> (compare with https://issues.apache.org/jira/browse/JCRVLT-140) it should
> also be possible to make this implicit dependency and explicit one (to make
> the validator be able to detect e.g. filter roots being provided by {{b}}).
> But once you also add {{a}} as dependency to {{b}} you get a dependency cycle.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-415) jackrabbit-emptyelements validator reports error for nested folders
[
https://issues.apache.org/jira/browse/JCRVLT-415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17046220#comment-17046220
]
Tobias Bocanegra commented on JCRVLT-415:
-
but then the importer is wrong. a directory below a filter root w/o a
{{.content.xml}} should have the nodetype {{nt:folder}}.
> jackrabbit-emptyelements validator reports error for nested folders
> ---
>
> Key: JCRVLT-415
> URL: https://issues.apache.org/jira/browse/JCRVLT-415
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Affects Versions: 3.4.2
>Reporter: Csaba Varga
>Priority: Minor
> Fix For: 3.4.4
>
> Attachments: test.zip, test2.zip
>
>
> When an nt:folder node is present under an orderable node, the
> "jackrabbit-emptyelements" validator will report an issue (breaking the build
> with the default settings of the package Maven plugin). I believe this
> shouldn't be reported as an issue because the AEM Package Manager can
> generate packages like this. For example, see the attached test.zip file,
> which was exported on an out-of-the-box AEM 6.5 instance with dummy nodes.
> To reproduce, save test.zip somewhere, then invoke the validation Maven goal
> in the command like like this:
> {{mvn org.apache.jackrabbit:filevault-package-maven-plugin:validate-package
> -Dvault.packageToValidate=test.zip}}
> test.zip contains the following very simple node hierarchy:
> {{/}}
> {{ test (nt:unstructured)}}
> {{ foo (nt:folder)}}
> {{ bar (nt:folder)}}
> {{ baz (sling:OrderedFolder)}}
> The error I'm getting is:
> {{[ERROR] ValidationViolation: "jackrabbit-emptyelements: Found empty nodes:
> '/test/foo' (in 'test\.content.xml') (used for ordering only) which are
> included in the filter with mode=merge. Rather use the according
> include/exclude patterns."}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-413) Clarify documentation about intermediate/ancestor nodes
[ https://issues.apache.org/jira/browse/JCRVLT-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17039756#comment-17039756 ] Tobias Bocanegra commented on JCRVLT-413: - if the parent is already a sling:Folder, it should create a sling:Folder child node, per definition of sling:Folder: https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/9862902975b330c42bd13de66278e090f947c709/src/main/resources/SLING-INF/nodetypes/folder.cnd#L26-L29 > Clarify documentation about intermediate/ancestor nodes > --- > > Key: JCRVLT-413 > URL: https://issues.apache.org/jira/browse/JCRVLT-413 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: vlt >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: 3.4.4 > > Attachments: test_intermediate-1.0.0 (2).zip > > > The documentation at http://jackrabbit.apache.org/filevault/filter.html > should be clarified with respect to ancestor nodes. > All *_uncovered_* ancestor nodes are > # created with the node type given in the package (in case they are given in > the package and not yet existing in the repo) > # created with node type "nt:folder" (in case they are not given in the > package and not yet existing in the repo) > # not touched (in case they are already existing in the repo) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCRVLT-413) Clarify documentation about intermediate/ancestor nodes
[ https://issues.apache.org/jira/browse/JCRVLT-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17039570#comment-17039570 ] Tobias Bocanegra commented on JCRVLT-413: - I think they are created with the default nodetype, which is determined by the node type declaration of its parent. e.g. if the parent node defines `sling:Folder` as default node type, then it will create `sling:Folders`. > Clarify documentation about intermediate/ancestor nodes > --- > > Key: JCRVLT-413 > URL: https://issues.apache.org/jira/browse/JCRVLT-413 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: vlt >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: 3.4.4 > > > The documentation at http://jackrabbit.apache.org/filevault/filter.html > should be clarified with respect to ancestor nodes. > All *_uncovered_* ancestor nodes are > # created with the node type given in the package (in case they are given in > the package and not yet existing in the repo) > # created with node type "nt:folder" (in case they are not given in the > package and not yet existing in the repo) > # not touched (in case they are already existing in the repo) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCRVLT-407) DocView XML: Proper namespace support for node names during import
[
https://issues.apache.org/jira/browse/JCRVLT-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17033830#comment-17033830
]
Tobias Bocanegra commented on JCRVLT-407:
-
I would assume that the filename's prefix is resolved using the namespace
declaration of it's XML, or its {{.content.xml}} if it's a directory, so:
{{_jcr2_content/.content.xml}}, or {{_jcr2_example.xml}}
we could add expanded format support for filenames, but it would look very
ugly
> DocView XML: Proper namespace support for node names during import
> --
>
> Key: JCRVLT-407
> URL: https://issues.apache.org/jira/browse/JCRVLT-407
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Affects Versions: 3.4.2
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 3.4.4
>
>
> Currently any DocView files is processed by the DocViewSAXImporter which
> creates in the end nodes in the repository via
> https://github.com/apache/jackrabbit-filevault/blob/e05e3fc8031eb08f6d0815316ec7fff3367df53c/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/DocViewSAXImporter.java#L800.
> That just takes {{DocViewNode}} as parameter. Unfortunately the node name is
> only contained there in its qualifed (i.e. prefixed) form
> (https://docs.adobe.com/docs/en/spec/jcr/2.0/3_Repository_Model.html#3.2.5.2%20Qualified%20Form).
> In case the XML uses other prefixes than the underlying JCR the namespaces
> won't be correctly resolved, as the node creation happens in
> https://github.com/apache/jackrabbit-filevault/blob/e05e3fc8031eb08f6d0815316ec7fff3367df53c/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/DocViewSAXImporter.java#L1050
> with just the qualified form.
> I would propose that the DocView node uses the expanded form
> (https://docs.adobe.com/docs/en/spec/jcr/2.0/3_Repository_Model.html#3.2.5.1%20Expanded%20Form)
> for node names, similar to property names!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-407) DocView XML: Proper namespace support for node names during import
[
https://issues.apache.org/jira/browse/JCRVLT-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17033817#comment-17033817
]
Tobias Bocanegra commented on JCRVLT-407:
-
well, then it's a bug :-) the {{ni.name}} should be converted to expanded form,
then everything should work.
> DocView XML: Proper namespace support for node names during import
> --
>
> Key: JCRVLT-407
> URL: https://issues.apache.org/jira/browse/JCRVLT-407
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Affects Versions: 3.4.2
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 3.4.4
>
>
> Currently any DocView files is processed by the DocViewSAXImporter which
> creates in the end nodes in the repository via
> https://github.com/apache/jackrabbit-filevault/blob/e05e3fc8031eb08f6d0815316ec7fff3367df53c/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/DocViewSAXImporter.java#L800.
> That just takes {{DocViewNode}} as parameter. Unfortunately the node name is
> only contained there in its qualifed (i.e. prefixed) form
> (https://docs.adobe.com/docs/en/spec/jcr/2.0/3_Repository_Model.html#3.2.5.2%20Qualified%20Form).
> In case the XML uses other prefixes than the underlying JCR the namespaces
> won't be correctly resolved, as the node creation happens in
> https://github.com/apache/jackrabbit-filevault/blob/e05e3fc8031eb08f6d0815316ec7fff3367df53c/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/DocViewSAXImporter.java#L1050
> with just the qualified form.
> I would propose that the DocView node uses the expanded form
> (https://docs.adobe.com/docs/en/spec/jcr/2.0/3_Repository_Model.html#3.2.5.1%20Expanded%20Form)
> for node names, similar to property names!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (JCRVLT-407) DocView XML: Proper namespace support for node names during import
[
https://issues.apache.org/jira/browse/JCRVLT-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17033809#comment-17033809
]
Tobias Bocanegra edited comment on JCRVLT-407 at 2/10/20 5:55 PM:
--
I still don't understand why this is a problem. the nodes and properties are
created using the session namespaces [0]. so even if the docview has a {{jcr2}}
prefix, it should endup as {{jcr:content}} node.
if this doesn't work, it's a bug.
[0]
https://github.com/apache/jackrabbit-filevault/blob/trunk/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/DocViewSAXImporter.java#L1047
was (Author: tripod):
I still don't understand why this is a problem. the nodes and properties are
created using the session namespaces [0]. so even if the docview has a {{jcr2}}
prefix, it should endup as {{jcr:content}} node.
if this doesn't work, it's a but.
[0]
https://github.com/apache/jackrabbit-filevault/blob/trunk/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/DocViewSAXImporter.java#L1047
> DocView XML: Proper namespace support for node names during import
> --
>
> Key: JCRVLT-407
> URL: https://issues.apache.org/jira/browse/JCRVLT-407
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Affects Versions: 3.4.2
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 3.4.4
>
>
> Currently any DocView files is processed by the DocViewSAXImporter which
> creates in the end nodes in the repository via
> https://github.com/apache/jackrabbit-filevault/blob/e05e3fc8031eb08f6d0815316ec7fff3367df53c/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/DocViewSAXImporter.java#L800.
> That just takes {{DocViewNode}} as parameter. Unfortunately the node name is
> only contained there in its qualifed (i.e. prefixed) form
> (https://docs.adobe.com/docs/en/spec/jcr/2.0/3_Repository_Model.html#3.2.5.2%20Qualified%20Form).
> In case the XML uses other prefixes than the underlying JCR the namespaces
> won't be correctly resolved, as the node creation happens in
> https://github.com/apache/jackrabbit-filevault/blob/e05e3fc8031eb08f6d0815316ec7fff3367df53c/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/DocViewSAXImporter.java#L1050
> with just the qualified form.
> I would propose that the DocView node uses the expanded form
> (https://docs.adobe.com/docs/en/spec/jcr/2.0/3_Repository_Model.html#3.2.5.1%20Expanded%20Form)
> for node names, similar to property names!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-407) DocView XML: Proper namespace support for node names during import
[
https://issues.apache.org/jira/browse/JCRVLT-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17033809#comment-17033809
]
Tobias Bocanegra commented on JCRVLT-407:
-
I still don't understand why this is a problem. the nodes and properties are
created using the session namespaces [0]. so even if the docview has a {{jcr2}}
prefix, it should endup as {{jcr:content}} node.
if this doesn't work, it's a but.
[0]
https://github.com/apache/jackrabbit-filevault/blob/trunk/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/DocViewSAXImporter.java#L1047
> DocView XML: Proper namespace support for node names during import
> --
>
> Key: JCRVLT-407
> URL: https://issues.apache.org/jira/browse/JCRVLT-407
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Affects Versions: 3.4.2
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 3.4.4
>
>
> Currently any DocView files is processed by the DocViewSAXImporter which
> creates in the end nodes in the repository via
> https://github.com/apache/jackrabbit-filevault/blob/e05e3fc8031eb08f6d0815316ec7fff3367df53c/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/DocViewSAXImporter.java#L800.
> That just takes {{DocViewNode}} as parameter. Unfortunately the node name is
> only contained there in its qualifed (i.e. prefixed) form
> (https://docs.adobe.com/docs/en/spec/jcr/2.0/3_Repository_Model.html#3.2.5.2%20Qualified%20Form).
> In case the XML uses other prefixes than the underlying JCR the namespaces
> won't be correctly resolved, as the node creation happens in
> https://github.com/apache/jackrabbit-filevault/blob/e05e3fc8031eb08f6d0815316ec7fff3367df53c/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/DocViewSAXImporter.java#L1050
> with just the qualified form.
> I would propose that the DocView node uses the expanded form
> (https://docs.adobe.com/docs/en/spec/jcr/2.0/3_Repository_Model.html#3.2.5.1%20Expanded%20Form)
> for node names, similar to property names!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-407) DocView XML: Proper namespace support for node names during import
[
https://issues.apache.org/jira/browse/JCRVLT-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17033798#comment-17033798
]
Tobias Bocanegra commented on JCRVLT-407:
-
I don't understand the problem. can you provide an example?
> DocView XML: Proper namespace support for node names during import
> --
>
> Key: JCRVLT-407
> URL: https://issues.apache.org/jira/browse/JCRVLT-407
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Affects Versions: 3.4.2
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 3.4.4
>
>
> Currently any DocView files is processed by the DocViewSAXImporter which
> creates in the end nodes in the repository via
> https://github.com/apache/jackrabbit-filevault/blob/e05e3fc8031eb08f6d0815316ec7fff3367df53c/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/DocViewSAXImporter.java#L800.
> That just takes {{DocViewNode}} as parameter. Unfortunately the node name is
> only contained there in its qualifed (i.e. prefixed) form
> (https://docs.adobe.com/docs/en/spec/jcr/2.0/3_Repository_Model.html#3.2.5.2%20Qualified%20Form).
> In case the XML uses other prefixes than the underlying JCR the namespaces
> won't be correctly resolved, as the node creation happens in
> https://github.com/apache/jackrabbit-filevault/blob/e05e3fc8031eb08f6d0815316ec7fff3367df53c/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/DocViewSAXImporter.java#L1050
> with just the qualified form.
> I would propose that the DocView node uses the expanded form
> (https://docs.adobe.com/docs/en/spec/jcr/2.0/3_Repository_Model.html#3.2.5.1%20Expanded%20Form)
> for node names, similar to property names!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-403) Clarify usage of package type "application" for overlays
[
https://issues.apache.org/jira/browse/JCRVLT-403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17023385#comment-17023385
]
Tobias Bocanegra commented on JCRVLT-403:
-
the {{tool-ancestor}} is given by the system. it provides
{{/apps/cq/core/content/nav/tools/security}} for example.
and {{tool-ancestor-foo}} would need to depend on {{tool-ancestor}} etc...
bq. 1. How does tool-ancestor-... define the ancestor nodes without using
include/excludes?
just as filter root. introducing excludes/includes was IMO a big mistake. it
would have been so much easier, if we just have complete sub-tree replacements.
bq. 2. What is the right installation order? tool-foo and tool-bar don't know
about each other and the ancestor packages will overwrite each other!
tool-foo and tool-bar need to reside on different subtrees. and their ancestor
package is provided by the system.
> Clarify usage of package type "application" for overlays
>
>
> Key: JCRVLT-403
> URL: https://issues.apache.org/jira/browse/JCRVLT-403
> Project: Jackrabbit FileVault
> Issue Type: Improvement
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 3.4.4
>
>
> According to JCRVLT-170 it is not allowed to use {{includes}} or {{excludes}}
> below a filter rule for {{application}} packages. This is a pretty common
> pattern though for including overlays in an apps package to enforce creating
> the ancestor nodes with the right type.
> See also
> https://issues.apache.org/jira/browse/JCRVLT-170?focusedCommentId=17016199=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17016199
> The use case of two different apps packages providing overlays below the same
> ancestor node should be supported (with both apps packages not knowing
> anything about each other) and still ensuring that the right node type is
> being created for ancestors.
> There must be a way of enforcing a certain ancestor node type during import
> and creating it in case it is not yet there, and failing in case if the
> ancestor is there with a different/incompatible type.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-403) Clarify usage of package type "application" for overlays
[
https://issues.apache.org/jira/browse/JCRVLT-403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17022764#comment-17022764
]
Tobias Bocanegra commented on JCRVLT-403:
-
the idea is that on re-install, the sub-packages would also be reinstalled.
also note that the subpackages don’t include ancestor nodes but are rooted at
the respective subtree.
> Clarify usage of package type "application" for overlays
>
>
> Key: JCRVLT-403
> URL: https://issues.apache.org/jira/browse/JCRVLT-403
> Project: Jackrabbit FileVault
> Issue Type: Improvement
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 3.4.4
>
>
> According to JCRVLT-170 it is not allowed to use {{includes}} or {{excludes}}
> below a filter rule for {{application}} packages. This is a pretty common
> pattern though for including overlays in an apps package to enforce creating
> the ancestor nodes with the right type.
> See also
> https://issues.apache.org/jira/browse/JCRVLT-170?focusedCommentId=17016199=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17016199
> The use case of two different apps packages providing overlays below the same
> ancestor node should be supported (with both apps packages not knowing
> anything about each other) and still ensuring that the right node type is
> being created for ancestors.
> There must be a way of enforcing a certain ancestor node type during import
> and creating it in case it is not yet there, and failing in case if the
> ancestor is there with a different/incompatible type.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-403) Clarify usage of package type "application" for overlays
[
https://issues.apache.org/jira/browse/JCRVLT-403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17022751#comment-17022751
]
Tobias Bocanegra commented on JCRVLT-403:
-
ideally there is a 3rd package that defines the ancestor nodes.
eg:
package {{security-tools}}:
{{}}
package {{tool-foo}}, depends on {{security-tools}}:
{{}}
package {{tool-bar}}, depends on {{security-tools}}:
{{}}
> Clarify usage of package type "application" for overlays
>
>
> Key: JCRVLT-403
> URL: https://issues.apache.org/jira/browse/JCRVLT-403
> Project: Jackrabbit FileVault
> Issue Type: Improvement
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 3.4.4
>
>
> According to JCRVLT-170 it is not allowed to use {{includes}} or {{excludes}}
> below a filter rule for {{application}} packages. This is a pretty common
> pattern though for including overlays in an apps package to enforce creating
> the ancestor nodes with the right type.
> See also
> https://issues.apache.org/jira/browse/JCRVLT-170?focusedCommentId=17016199=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17016199
> The use case of two different apps packages providing overlays below the same
> ancestor node should be supported (with both apps packages not knowing
> anything about each other) and still ensuring that the right node type is
> being created for ancestors.
> There must be a way of enforcing a certain ancestor node type during import
> and creating it in case it is not yet there, and failing in case if the
> ancestor is there with a different/incompatible type.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-401) Clarify allowed contents of container package type
[ https://issues.apache.org/jira/browse/JCRVLT-401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17020864#comment-17020864 ] Tobias Bocanegra commented on JCRVLT-401: - I think having containers in containers is useful. but I would avoid having it mixed with other types. > Clarify allowed contents of container package type > -- > > Key: JCRVLT-401 > URL: https://issues.apache.org/jira/browse/JCRVLT-401 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: vlt >Affects Versions: 3.4.2 >Reporter: Konrad Windszus >Priority: Major > Fix For: 3.4.4 > > > This is a follow up to JCRVLT-170 to clarify if containers are allowed to > contain packages of type "content", "container" and/or "mixed". > See also > https://issues.apache.org/jira/browse/JCRVLT-170?focusedCommentId=17012844=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17012844 > and the discussion at > https://lists.apache.org/thread.html/r36a13cf204fcb570648c18f9c9feb8f72b83fdd276a200718b069fcf%40%3Cdev.jackrabbit.apache.org%3E. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCRVLT-170) Introduce the concept of package types
[ https://issues.apache.org/jira/browse/JCRVLT-170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17014787#comment-17014787 ] Tobias Bocanegra commented on JCRVLT-170: - [~dsuess] WDYT? > Introduce the concept of package types > -- > > Key: JCRVLT-170 > URL: https://issues.apache.org/jira/browse/JCRVLT-170 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: Packaging >Reporter: Tobias Bocanegra >Assignee: Tobias Bocanegra >Priority: Major > Fix For: 3.1.42 > > > h1. Overview > content packages can be used for various purposes and this should be > reflected by package types. the types distinguish primarily between packages > with code and packages with content. other types are container packages that > only contain sub-packages. > h2. Application Packages > For code deployment scenarios the simplicity of filter roots and the accuracy > of dependencies is more important than for normal content packages. > The application packages have the characteristic that: > - they only provide content to /apps, /libs (thus are instance private) > - they only contain disjunct subtrees (i.e. not include/exclude in the filter > patterns) > - don't create snapshots when installed, i.e. uninstalling them means > deleting the content below the subtree and installing the previous version > - don't include sub-packages > - don't include OSGi configuration or bundles > - define proper dependencies to other application packages (i.e. all ancestor > paths of their import filters must be covered by one dependent package) > - do not include oak index definitions > - do not include hooks > h2. Content Packages > The content packages contain content and user configuration > - don't have content below /apps or /libs > - don't include OSGi configuration or bundles > - can have sub-packages to other content packages (but not to app packages) > h2. Container Packages > As for the container / deployment packages they have the characteristics that: > - they don't contain any content > - they contain a set of application content packages > - they don't have dependencies on other deployment packages (i.e. the > dependencies are implicit given by the relations of the included artifacts) > It is to discuss if the container packages should be allowed to carry bundles > and config. maybe they should be handled completely different, such as using > sling provisioning. > h2. Mixed Package > This is the catch-all case of the above for legacy content. Ideally we don't > have any of those on the long run. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCRVLT-255) ImportModes act on file serialization level not on node level
[
https://issues.apache.org/jira/browse/JCRVLT-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17010472#comment-17010472
]
Tobias Bocanegra commented on JCRVLT-255:
-
well, it seems that
- basically, the import mode is applied on artifcats and on policy/principal
nodes.
- merging docview artifacts is not supported. i.e. if you have a
{{fullcoverage.xml}} it will be ignored
- merging generic artifcats (eg: dir+.content.xml), will only work on node
level, i.e. MERGE and UPDATE handled the same for normal nodes, but special for
policy nodes.
it might be that the special case for docview artifacts is a leftover from
older times...so maybe they could be treated like generic files and merge
accordingly.
> ImportModes act on file serialization level not on node level
> -
>
> Key: JCRVLT-255
> URL: https://issues.apache.org/jira/browse/JCRVLT-255
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 3.4.4
>
>
> When reading the docs at
> http://jackrabbit.apache.org/filevault/importmode.html I would assume that
> for {{ImportMode.MERGE}} the merging happens on node level (i.e. indepent of
> the actual serialization format). Unfortunately this is not the case: If I
> have a serialized docview {{.content.xml}} file covering the current node and
> three levels below the merging is not done if the entry node level does
> already exist in the repository, although not all child nodes are in the
> repository yet.
> This is due to the guard in
> https://github.com/apache/jackrabbit-filevault/blob/8b2fedaf329b3bf4a049e41563c0bc83487406f7/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/FileArtifactHandler.java#L226.
> which prevents the DocViewSAXImporter from kicking in, although there are
> indeed subnodes in the {{.content.xml}} which are not yet in the repository.
> Please either fix this behaviour of make the documentation at
> http://jackrabbit.apache.org/filevault/importmode.html clearer because it
> explicitly says there:
> {quote}
> It is important to note, that the import mode always operates on entire nodes
> and subtrees...
> {quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-255) ImportModes act on file serialization level not on node level
[
https://issues.apache.org/jira/browse/JCRVLT-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17010249#comment-17010249
]
Tobias Bocanegra commented on JCRVLT-255:
-
bq. I translate this to: "New properties are added, existing properties are
updated, none are deleted and no existing nodes are deleted (but new child
nodes are added)". Is this understanding correct?
yes, but since this would be a backward incompatible change, maybe we should
add a {{MERGE_PROPERTIES}} mode?
> ImportModes act on file serialization level not on node level
> -
>
> Key: JCRVLT-255
> URL: https://issues.apache.org/jira/browse/JCRVLT-255
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 3.4.2
>
>
> When reading the docs at
> http://jackrabbit.apache.org/filevault/importmode.html I would assume that
> for {{ImportMode.MERGE}} the merging happens on node level (i.e. indepent of
> the actual serialization format). Unfortunately this is not the case: If I
> have a serialized docview {{.content.xml}} file covering the current node and
> three levels below the merging is not done if the entry node level does
> already exist in the repository, although not all child nodes are in the
> repository yet.
> This is due to the guard in
> https://github.com/apache/jackrabbit-filevault/blob/8b2fedaf329b3bf4a049e41563c0bc83487406f7/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/FileArtifactHandler.java#L226.
> which prevents the DocViewSAXImporter from kicking in, although there are
> indeed subnodes in the {{.content.xml}} which are not yet in the repository.
> Please either fix this behaviour of make the documentation at
> http://jackrabbit.apache.org/filevault/importmode.html clearer because it
> explicitly says there:
> {quote}
> It is important to note, that the import mode always operates on entire nodes
> and subtrees...
> {quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-391) Remove copied classes of Xerces
[
https://issues.apache.org/jira/browse/JCRVLT-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16993552#comment-16993552
]
Tobias Bocanegra commented on JCRVLT-391:
-
yes. please go ahead. thanks for all the work!
> Remove copied classes of Xerces
> ---
>
> Key: JCRVLT-391
> URL: https://issues.apache.org/jira/browse/JCRVLT-391
> Project: Jackrabbit FileVault
> Issue Type: Task
> Components: vlt
>Affects Versions: 3.4.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.4.2
>
>
> Currently the classes below {{o.a.j.v.util.xml}} seem to be a copy of Xerces
> classes. Instead of just relying on an old copy one should use a proper Maven
> dependency together with https://maven.apache.org/plugins/maven-shade-plugin/
> or https://bnd.bndtools.org/instructions/conditionalpackage.html to make sure
> update to the latest version is possible.
> Also it needs to be clarified if the embedded Xerces should be listed
> explicitly in
> https://github.com/apache/jackrabbit-filevault/blob/trunk/LICENSE.txt.
> The original intent is stated in
> https://github.com/apache/jackrabbit-filevault/blob/9fa6c72bf4bdf36331b50b9370f3ed826a4622e8/vault-core/src/main/java/org/apache/jackrabbit/vault/util/xml/serialize/XMLSerializer.java#L64.
> The only modifications to the original Xerces were linebreaks after
> attributes and an alphabetic attribute sort order.
> The following alternatives are available:
> # Use the {{javax.xml.transform}} API (JAXP Transformation API, TrAX). There
> is no official way though to control the order of attribute, therefore I
> would recommend to already emit the attributes in the correct order instead
> of reordering them with the output. Controlling the indentation of
> attributes is hard to achieve:
> https://stackoverflow.com/questions/8393370/use-xslt-to-add-newlines-after-attributes
> # Use StAX with the Woodstox implementation. Seems faster, but still no
> sophisticated output formatting options available (like indentation options
> and line length)
> # Implement a simple serializer based on SAX events from scratch
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-391) Remove copied classes of Xerces
[
https://issues.apache.org/jira/browse/JCRVLT-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16986728#comment-16986728
]
Tobias Bocanegra commented on JCRVLT-391:
-
I confused the EPL with EDL; In fact, *Eclipse Distribution License 1.0* it is
a category a. (the EPL is category-b).
So this should be ok.
> What Adobe thinks about this, is not that important IMHO,
well, yes and no. if we add a dependency with a problematic license, and Adobe
doesn't allow it in the product, then we effectively can't use this project
anymore. So any customers relying on new features and bug fixes would be
impacted as well.
> Remove copied classes of Xerces
> ---
>
> Key: JCRVLT-391
> URL: https://issues.apache.org/jira/browse/JCRVLT-391
> Project: Jackrabbit FileVault
> Issue Type: Task
> Components: vlt
>Affects Versions: 3.4.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.4.2
>
>
> Currently the classes below {{o.a.j.v.util.xml}} seem to be a copy of Xerces
> classes. Instead of just relying on an old copy one should use a proper Maven
> dependency together with https://maven.apache.org/plugins/maven-shade-plugin/
> or https://bnd.bndtools.org/instructions/conditionalpackage.html to make sure
> update to the latest version is possible.
> Also it needs to be clarified if the embedded Xerces should be listed
> explicitly in
> https://github.com/apache/jackrabbit-filevault/blob/trunk/LICENSE.txt.
> The original intent is stated in
> https://github.com/apache/jackrabbit-filevault/blob/9fa6c72bf4bdf36331b50b9370f3ed826a4622e8/vault-core/src/main/java/org/apache/jackrabbit/vault/util/xml/serialize/XMLSerializer.java#L64.
> The only modifications to the original Xerces were linebreaks after
> attributes and an alphabetic attribute sort order.
> The following alternatives are available:
> # Use the {{javax.xml.transform}} API (JAXP Transformation API, TrAX). There
> is no official way though to control the order of attribute, therefore I
> would recommend to already emit the attributes in the correct order instead
> of reordering them with the output. Controlling the indentation of
> attributes is hard to achieve:
> https://stackoverflow.com/questions/8393370/use-xslt-to-add-newlines-after-attributes
> # Use StAX with the Woodstox implementation. Seems faster, but still no
> sophisticated output formatting options available (like indentation options
> and line length)
> # Implement a simple serializer based on SAX events from scratch
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-391) Remove copied classes of Xerces
[
https://issues.apache.org/jira/browse/JCRVLT-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16986464#comment-16986464
]
Tobias Bocanegra commented on JCRVLT-391:
-
the Eclipse Distribution License is better, but we would need to check with
Adobe Legal, before we can include it in the product.
I would prefer a solution w/o a _problematic_ license.
> WDYT about the max line length?
I don't think this is a problem.
> Remove copied classes of Xerces
> ---
>
> Key: JCRVLT-391
> URL: https://issues.apache.org/jira/browse/JCRVLT-391
> Project: Jackrabbit FileVault
> Issue Type: Task
> Components: vlt
>Affects Versions: 3.4.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.4.2
>
>
> Currently the classes below {{o.a.j.v.util.xml}} seem to be a copy of Xerces
> classes. Instead of just relying on an old copy one should use a proper Maven
> dependency together with https://maven.apache.org/plugins/maven-shade-plugin/
> or https://bnd.bndtools.org/instructions/conditionalpackage.html to make sure
> update to the latest version is possible.
> Also it needs to be clarified if the embedded Xerces should be listed
> explicitly in
> https://github.com/apache/jackrabbit-filevault/blob/trunk/LICENSE.txt.
> The original intent is stated in
> https://github.com/apache/jackrabbit-filevault/blob/9fa6c72bf4bdf36331b50b9370f3ed826a4622e8/vault-core/src/main/java/org/apache/jackrabbit/vault/util/xml/serialize/XMLSerializer.java#L64.
> The only modifications to the original Xerces were linebreaks after
> attributes and an alphabetic attribute sort order.
> The following alternatives are available:
> # Use the {{javax.xml.transform}} API (JAXP Transformation API, TrAX). There
> is no official way though to control the order of attribute, therefore I
> would recommend to already emit the attributes in the correct order instead
> of reordering them with the output. Controlling the indentation of
> attributes is hard to achieve:
> https://stackoverflow.com/questions/8393370/use-xslt-to-add-newlines-after-attributes
> # Use StAX with the Woodstox implementation. Seems faster, but still no
> sophisticated output formatting options available (like indentation options
> and line length)
> # Implement a simple serializer based on SAX events from scratch
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-391) Remove copied classes of Xerces
[
https://issues.apache.org/jira/browse/JCRVLT-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16985726#comment-16985726
]
Tobias Bocanegra commented on JCRVLT-391:
-
{noformat}
org.glassfish.jaxb
txw2
2.3.2
{noformat}
AFAICS, this has a *CDDL+GPL License*
https://mvnrepository.com/artifact/org.glassfish.jaxb/txw2/2.3.1
which is problematic to use. we cannot embed it and we (adobe) cannot put it
into our products. can you find another library?
(com.fasterxml.woodstox is Apache-2.0 licensed, so no problem.)
> Remove copied classes of Xerces
> ---
>
> Key: JCRVLT-391
> URL: https://issues.apache.org/jira/browse/JCRVLT-391
> Project: Jackrabbit FileVault
> Issue Type: Task
> Components: vlt
>Affects Versions: 3.4.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.4.2
>
>
> Currently the classes below {{o.a.j.v.util.xml}} seem to be a copy of Xerces
> classes. Instead of just relying on an old copy one should use a proper Maven
> dependency together with https://maven.apache.org/plugins/maven-shade-plugin/
> or https://bnd.bndtools.org/instructions/conditionalpackage.html to make sure
> update to the latest version is possible.
> Also it needs to be clarified if the embedded Xerces should be listed
> explicitly in
> https://github.com/apache/jackrabbit-filevault/blob/trunk/LICENSE.txt.
> The original intent is stated in
> https://github.com/apache/jackrabbit-filevault/blob/9fa6c72bf4bdf36331b50b9370f3ed826a4622e8/vault-core/src/main/java/org/apache/jackrabbit/vault/util/xml/serialize/XMLSerializer.java#L64.
> The only modifications to the original Xerces were linebreaks after
> attributes and an alphabetic attribute sort order.
> The following alternatives are available:
> # Use the {{javax.xml.transform}} API (JAXP Transformation API, TrAX). There
> is no official way though to control the order of attribute, therefore I
> would recommend to already emit the attributes in the correct order instead
> of reordering them with the output. Controlling the indentation of
> attributes is hard to achieve:
> https://stackoverflow.com/questions/8393370/use-xslt-to-add-newlines-after-attributes
> # Use StAX with the Woodstox implementation. Seems faster, but still no
> sophisticated output formatting options available (like indentation options
> and line length)
> # Implement a simple serializer based on SAX events from scratch
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-394) Get rid of "provided" scope for FileVault dependencies
[
https://issues.apache.org/jira/browse/JCRVLT-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16981982#comment-16981982
]
Tobias Bocanegra commented on JCRVLT-394:
-
I would not change the scope because the primary use is in an osgi context.
users that want to use it directly, can still specify the dependencies
explicitly.
alternatively, we could create a `filevault-all` project that has all the
dependencies with a different scope.
> Get rid of "provided" scope for FileVault dependencies
> --
>
> Key: JCRVLT-394
> URL: https://issues.apache.org/jira/browse/JCRVLT-394
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: vlt
>Affects Versions: 3.4.0
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 3.4.2
>
>
> Almost all dependencies of Jackrabbit FileVault have scope "provided".
> Although in an OSGi context this seems reasonable, FileVault is also used
> outside of OSGi (e.g. within filevault-package-maven-plugin). Using it may
> lead to the following exceptions
> {code}
> java.lang.NoClassDefFoundError: org/apache/jackrabbit/api/ReferenceBinary
> at
> org.apache.jackrabbit.vault.validation.impl.util.DocumentViewXmlContentHandler.getDocViewNode
> (DocumentViewXmlContentHandler.java:163)
> at
> org.apache.jackrabbit.vault.validation.impl.util.DocumentViewXmlContentHandler.startElement
> (DocumentViewXmlContentHandler.java:134)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement
> (AbstractSAXParser.java:509)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractXMLDocumentParser.emptyElement
> (AbstractXMLDocumentParser.java:182)
> at
> com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement
> (XMLNSDocumentScannerImpl.java:351)
> at
> com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl$NSContentDriver.scanRootElementHook
> (XMLNSDocumentScannerImpl.java:613)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next
> (XMLDocumentFragmentScannerImpl.java:3132)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next
> (XMLDocumentScannerImpl.java:852)
> at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next
> (XMLDocumentScannerImpl.java:602)
> at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next
> (XMLNSDocumentScannerImpl.java:112)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument
> (XMLDocumentFragmentScannerImpl.java:505)
> at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse
> (XML11Configuration.java:842)
> at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse
> (XML11Configuration.java:771)
> at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse
> (XMLParser.java:141)
> at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse
> (AbstractSAXParser.java:1213)
> at
> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse
> (SAXParserImpl.java:643)
> at
> org.apache.jackrabbit.vault.validation.spi.impl.DocumentViewParserValidator.validateDocumentViewXml
> (DocumentViewParserValidator.java:147)
> at
> org.apache.jackrabbit.vault.validation.spi.impl.DocumentViewParserValidator.validateJcrData
> (DocumentViewParserValidator.java:82)
> at
> org.apache.jackrabbit.vault.validation.ValidationExecutor.validateGenericJcrData
> (ValidationExecutor.java:279)
> at
> org.apache.jackrabbit.vault.validation.ValidationExecutor.validateJcrRoot
> (ValidationExecutor.java:181)
> at
> org.apache.jackrabbit.filevault.maven.packaging.ValidatePackageMojo.validateInputStream
> (ValidatePackageMojo.java:120)
> at
> org.apache.jackrabbit.filevault.maven.packaging.ValidatePackageMojo.validateEntry
> (ValidatePackageMojo.java:106)
> at
> org.apache.jackrabbit.filevault.maven.packaging.ValidatePackageMojo.validateEntry
> (ValidatePackageMojo.java:103)
> at
> org.apache.jackrabbit.filevault.maven.packaging.ValidatePackageMojo.validateEntry
> (ValidatePackageMojo.java:103)
> at
> org.apache.jackrabbit.filevault.maven.packaging.ValidatePackageMojo.validateEntry
> (ValidatePackageMojo.java:103)
> at
> org.apache.jackrabbit.filevault.maven.packaging.ValidatePackageMojo.validateArchive
> (ValidatePackageMojo.java:95)
> at
> org.apache.jackrabbit.filevault.maven.packaging.ValidatePackageMojo.validatePackage
> (ValidatePackageMojo.java:85)
> at
> org.apache.jackrabbit.filevault.maven.packaging.ValidatePackageMojo.doExecute
> (ValidatePackageMojo.java:66)
> at
>
[jira] [Commented] (JCRVLT-391) Remove copied classes of Xerces
[
https://issues.apache.org/jira/browse/JCRVLT-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16976999#comment-16976999
]
Tobias Bocanegra commented on JCRVLT-391:
-
it's not only the ordering of the attributes, it's also having a well defined,
fixed, reproducible outputformat for the serialized nodes.
this is especially important since the exports are usually stored in a SCM. if
each _sync_ would cause a different formatting, due to user preferences or
hashmap ordering, there would be a lot of false positive in respect to modified
files.
except for the not-so-nice code duplication, I don't see any problem why we
shouldn't keep the current copy of xecres. is there a concrete reason you want
to update xecres?
the other drawback using a transformer could be the impact on performance.
> Remove copied classes of Xerces
> ---
>
> Key: JCRVLT-391
> URL: https://issues.apache.org/jira/browse/JCRVLT-391
> Project: Jackrabbit FileVault
> Issue Type: Task
> Components: vlt
>Affects Versions: 3.4.0
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 3.4.2
>
>
> Currently the classes below {{o.a.j.v.util.xml}} seem to be a copy of Xerces
> classes. Instead of just relying on an old copy one should use a proper Maven
> dependency together with https://maven.apache.org/plugins/maven-shade-plugin/
> or https://bnd.bndtools.org/instructions/conditionalpackage.html to make sure
> update to the latest version is possible.
> Also it needs to be clarified if the embedded Xerces should be listed
> explicitly in
> https://github.com/apache/jackrabbit-filevault/blob/trunk/LICENSE.txt.
> The original intent is stated in
> https://github.com/apache/jackrabbit-filevault/blob/9fa6c72bf4bdf36331b50b9370f3ed826a4622e8/vault-core/src/main/java/org/apache/jackrabbit/vault/util/xml/serialize/XMLSerializer.java#L64.
> The only modifications to the original Xerces were linebreaks after
> attributes and an alphabetic attribute sort order.
> The alternative is to use the {{javax.xml.transform}} API (JAXP
> Transformation API). There is no official way though to control the order of
> attribute, therefore I would recommend to already emit the attributes in the
> correct order instead of reordering them with the output. Controlling the
> indentation of attributes is hard to achieve:
> https://stackoverflow.com/questions/8393370/use-xslt-to-add-newlines-after-attributes
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-390) filter based on content properties is not working
[
https://issues.apache.org/jira/browse/JCRVLT-390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16974725#comment-16974725
]
Tobias Bocanegra commented on JCRVLT-390:
-
I would need to debug it...
> filter based on content properties is not working
> -
>
> Key: JCRVLT-390
> URL: https://issues.apache.org/jira/browse/JCRVLT-390
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Affects Versions: 3.2.8
>Reporter: Om Pandey
>Priority: Minor
>
> We have a use case where the replication agent's *enabled* flag should not be
> overwritten with every deployment.
> Referring to the comment here
> https://issues.apache.org/jira/browse/JCRVLT-120?focusedCommentId=16907459=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16907459
> and the documentation for Property Filtering on
> [https://jackrabbit.apache.org/filevault/filter.html] , I am trying to
> implement this
> {code:java}
>
>
>
>
> {code}
> But when I deploy the package using this filter definition, the exclude
> pattern is not applied. Ideally this should include everything below the
> specified path and just ignore the property enabled in the existing content.
> But this is not happening as the whole content is replaced.
>
> We are using this in AEM with the version
> 3.2.8([org.apache.jackrabbit.vault|http://localhost:4502/system/console/bundles/150])
>
> the Node structure is:
>
> +/etc/replication/agents.author/some-data-exporter
> + jcr:content/
> - enabled="true"
> - property1="some value"
> - property2="some other value"
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-371) Include Maven groupId and artifactId of each dependency in the MANIFEST.MF and the properties.xml
[ https://issues.apache.org/jira/browse/JCRVLT-371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16955871#comment-16955871 ] Tobias Bocanegra commented on JCRVLT-371: - +1 > Include Maven groupId and artifactId of each dependency in the MANIFEST.MF > and the properties.xml > - > > Key: JCRVLT-371 > URL: https://issues.apache.org/jira/browse/JCRVLT-371 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: package maven plugin >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: package-maven-plugin-1.0.5 > > > To be able to do some static code analysis on existing packages it would be > helpful if package dependencies would not only be given via the Package ID > but also in a dedicated Manifest header with Maven groupId and artifactId. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCRVLT-371) Include Maven groupId and artifactId of each dependency in the MANIFEST.MF and the properties.xml
[
https://issues.apache.org/jira/browse/JCRVLT-371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16955844#comment-16955844
]
Tobias Bocanegra commented on JCRVLT-371:
-
what would be an example of the {{Package-Dependencies-Location}} properties?
> Include Maven groupId and artifactId of each dependency in the MANIFEST.MF
> and the properties.xml
> -
>
> Key: JCRVLT-371
> URL: https://issues.apache.org/jira/browse/JCRVLT-371
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: package maven plugin
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: package-maven-plugin-1.0.5
>
>
> To be able to do some static code analysis on existing packages it would be
> helpful if package dependencies would not only be given via the Package ID
> but also in a dedicated Manifest header with Maven groupId and artifactId.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-351) IOE thrown in case of no filter and false
[
https://issues.apache.org/jira/browse/JCRVLT-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952433#comment-16952433
]
Tobias Bocanegra commented on JCRVLT-351:
-
yes...as I said: +1 :-)
> IOE thrown in case of no filter and
> false
>
>
> Key: JCRVLT-351
> URL: https://issues.apache.org/jira/browse/JCRVLT-351
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.4
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: package-maven-plugin-1.0.5
>
>
> If I build a package which does neither have a generated nor a manually
> crafted filter and {{failOnEmptyFilter}} is set to {{false}} the following
> exception can be observed:
> {code}
> [WARNING] No workspace filter defined. Package import might have unexpected
> results.
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 2.858 s
> [INFO] Finished at: 2019-08-09T15:22:15+02:00
> [INFO]
>
> [DEBUG] No threads registered for execution at the end of the build
> [ERROR] Failed to execute goal
> org.apache.jackrabbit:filevault-package-maven-plugin:1.0.5-SNAPSHOT:generate-metadata
> (default-generate-metadata) on project complete-package:
> java.io.IOException: File
> /Users/konradwindszus//src/main/META-INF/vault/filter.xml does not
> exist -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal
> org.apache.jackrabbit:filevault-package-maven-plugin:1.0.5-SNAPSHOT:generate-metadata
> (default-generate-metadata) on project : java.io.IOException:
> File /Users/konradwindszus//src/main/META-INF/vault/filter.xml
> does not exist
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:215)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:956)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:192)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
> Caused by: org.apache.maven.plugin.MojoExecutionException:
> java.io.IOException: File
> /Users/konradwindszus//src/main/META-INF/vault/filter.xml does not
> exist
> at
> org.apache.jackrabbit.filevault.maven.packaging.GenerateMetadataMojo.execute(GenerateMetadataMojo.java:479)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210)
> ... 20 more
> Caused by: java.io.IOException: File
> /Users/konradwindszus//src/main/META-INF/vault/filter.xml does not
> exist
> at org.codehaus.plexus.util.FileUtils.copyFile(FileUtils.java:1074)
> at
> org.apache.jackrabbit.filevault.maven.packaging.GenerateMetadataMojo.computePackageFilters(GenerateMetadataMojo.java:593)
> at
>
[jira] [Commented] (JCRVLT-370) New filter option below embeddeds and subpackages which removes other versions
[
https://issues.apache.org/jira/browse/JCRVLT-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16951449#comment-16951449
]
Tobias Bocanegra commented on JCRVLT-370:
-
I think this is an edge case. for production systems, you don't want to remove
the old bundle, as it will be more difficult to revert.
If still desired, the user can add the respective filter himself.
> New filter option below embeddeds and subpackages which removes other versions
> --
>
> Key: JCRVLT-370
> URL: https://issues.apache.org/jira/browse/JCRVLT-370
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: package maven plugin
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: package-maven-plugin-1.0.5
>
>
> Currently if the {{filter}} option is set below embeddeds or subpackages a
> very specific filter entry is added to the filter.xml. That leads to the fact
> that other versions of the same package/bundle are not getting removed.
> Very often in a CI environment it is desired to remove all other versions,
> therefore I propose to add another option {{filterWithoutVersion}} which will
> make sure that OSGi bundles with the same name but another version and sub
> packages with the same name and group but another version are still removed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-345) Support pluggable node/file/filter validators
[
https://issues.apache.org/jira/browse/JCRVLT-345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16941415#comment-16941415
]
Tobias Bocanegra commented on JCRVLT-345:
-
looks good to me... In any case, we should avoid that the core bundle has a
dependency to the validation bundle...which AFAICS it doesn't .
> Support pluggable node/file/filter validators
> -
>
> Key: JCRVLT-345
> URL: https://issues.apache.org/jira/browse/JCRVLT-345
> Project: Jackrabbit FileVault
> Issue Type: New Feature
> Components: package maven plugin
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.4.2, package-maven-plugin-1.0.5
>
>
> IMHO it would be good to support pluggable node, file and filter.xml
> validators for custom validations:
> The filevault-package-m-p should ship/ships with these ones out of the box
> # check for index definition nodes
> # check for bundles, OSGi configuration and subpackages (in the context of
> JCRVLT-249)
> # check for adherence to the FileVault DocView for .content.xml files
> # check for filter.xml coverage of all nodes/files
> The following ones are just ideas for custom validations:
> # check for usage of deprecated resource types
> # check for content classification
> (https://helpx.adobe.com/experience-manager/6-5/sites/deploying/using/sustainable-upgrades.html)
> An SPI should be defined and allow everyone to come up with validator
> extensions which are automatically executed during the {{package}} goal on
> all files/nodes being included in the package
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-376) test cases leak temp files
[ https://issues.apache.org/jira/browse/JCRVLT-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16936434#comment-16936434 ] Tobias Bocanegra commented on JCRVLT-376: - LGTM. thanks for the patch > test cases leak temp files > -- > > Key: JCRVLT-376 > URL: https://issues.apache.org/jira/browse/JCRVLT-376 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: vlt >Reporter: Julian Reschke >Priority: Minor > Attachments: JCRVLT-376.diff > > > Many files matching "vaulttest*zip" are left in the tmp folder when running > tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (JCRVLT-376) test cases leak temp files
[ https://issues.apache.org/jira/browse/JCRVLT-376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Bocanegra updated JCRVLT-376: Fix Version/s: 3.4.2 > test cases leak temp files > -- > > Key: JCRVLT-376 > URL: https://issues.apache.org/jira/browse/JCRVLT-376 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: vlt >Reporter: Julian Reschke >Priority: Minor > Fix For: 3.4.2 > > Attachments: JCRVLT-376.diff > > > Many files matching "vaulttest*zip" are left in the tmp folder when running > tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCRVLT-375) Vault contains AEM specific nodetypes
[ https://issues.apache.org/jira/browse/JCRVLT-375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16934244#comment-16934244 ] Tobias Bocanegra commented on JCRVLT-375: - there are not many products that use filevault - and we don't have a good extension mechanism for the configs :-) I'm happy to add more configs for other products, if needed. But we cannot remove those w/o breaking AEM. > Vault contains AEM specific nodetypes > - > > Key: JCRVLT-375 > URL: https://issues.apache.org/jira/browse/JCRVLT-375 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: vlt >Affects Versions: 3.2.8 >Reporter: Jörg Hoh >Priority: Major > > The vault sourcecode [1] and also the binary packages of vault contain > proprietary nodetypes of Adobe Experience Manager (cq:Widget, cq:EditConfig, > ...) > Shouldn't that get removed? > [1]https://github.com/apache/jackrabbit-filevault/blob/trunk/vault-core/src/main/resources/org/apache/jackrabbit/vault/fs/config/defaultConfig-1.1.xml -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCRVLT-372) Clarify import and export behaviour for rep:policy nodes not contained in filter rules
[
https://issues.apache.org/jira/browse/JCRVLT-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16931989#comment-16931989
]
Tobias Bocanegra commented on JCRVLT-372:
-
{{rep:policy}} nodes should obey the same filter logic as all other nodes.
everything else is a bug.
however, during import, the special access control mode is used to further
handle the nodes.
special case is probably the clear + not in filter, like when only including a
node and not its children. but still then, it should not remove the AC if it's
not in the filter.
> Clarify import and export behaviour for rep:policy nodes not contained in
> filter rules
> --
>
> Key: JCRVLT-372
> URL: https://issues.apache.org/jira/browse/JCRVLT-372
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: vlt
>Reporter: Konrad Windszus
>Priority: Major
>
> It seems that {{rep:policy}} nodes do not necessarily have to be mentioned in
> the {{filter.xml}} for being considered during package import and export.
> That should be clarified in
> https://jackrabbit.apache.org/filevault/filter.html.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCR-4479) dist.apache.org must not be used for public downloads
[
https://issues.apache.org/jira/browse/JCR-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929689#comment-16929689
]
Tobias Bocanegra commented on JCR-4479:
---
ok, fixed in r1866918.
[~sebb] I noticed that {{.md}} extension is not served as text/plain, which
makes the release notes a bit ugly:
https://www.apache.org/dist/jackrabbit/filevault-package-maven-plugin/1.0.4/RELEASE-NOTES.md
where as on dist, the mime types are configured correctly:
https://dist.apache.org/repos/dist/release/jackrabbit//filevault-package-maven-plugin/1.0.4/RELEASE-NOTES.md
> dist.apache.org must not be used for public downloads
> -
>
> Key: JCR-4479
> URL: https://issues.apache.org/jira/browse/JCR-4479
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Reporter: Sebb
>Priority: Major
>
> The download page currently links to dist.apache.org for at least one
> artifact.
> The host dist.a.o is not intended for public downloads.
> Please replace the links with the proper www.apache.org/dist URLs
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Resolved] (JCR-4479) dist.apache.org must not be used for public downloads
[ https://issues.apache.org/jira/browse/JCR-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Bocanegra resolved JCR-4479. --- Resolution: Fixed > dist.apache.org must not be used for public downloads > - > > Key: JCR-4479 > URL: https://issues.apache.org/jira/browse/JCR-4479 > Project: Jackrabbit Content Repository > Issue Type: Bug >Reporter: Sebb >Priority: Major > > The download page currently links to dist.apache.org for at least one > artifact. > The host dist.a.o is not intended for public downloads. > Please replace the links with the proper www.apache.org/dist URLs -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (JCRVLT-367) CLONE - vlt shell script prints out error when using openjdk
[
https://issues.apache.org/jira/browse/JCRVLT-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16926334#comment-16926334
]
Tobias Bocanegra commented on JCRVLT-367:
-
ok then! go ahead.
> CLONE - vlt shell script prints out error when using openjdk
>
>
> Key: JCRVLT-367
> URL: https://issues.apache.org/jira/browse/JCRVLT-367
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.2.8
>Reporter: Robert Munteanu
>Priority: Minor
> Fix For: 3.4.0
>
> Attachments: JCRVLT-367-remove-version-parsing-v01.patch
>
>
> {noformat}$ vlt --version
> /usr/bin/vlt: line 146: [: 110 2019-07-16: integer expression expected
> Jackrabbit FileVault [version 3.2.8] Copyright 2018 by Apache Software
> Foundation. See LICENSE.txt for more information.{noformat}
> {noformat}$ java -version
> openjdk version "11.0.4" 2019-07-16
> OpenJDK Runtime Environment (build 11.0.4+11-suse-1.1-x8664)
> OpenJDK 64-Bit Server VM (build 11.0.4+11-suse-1.1-x8664, mixed
> mode){noformat}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (JCRVLT-367) CLONE - vlt shell script prints out error when using openjdk
[
https://issues.apache.org/jira/browse/JCRVLT-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra updated JCRVLT-367:
Fix Version/s: (was: 3.4.2)
3.4.0
> CLONE - vlt shell script prints out error when using openjdk
>
>
> Key: JCRVLT-367
> URL: https://issues.apache.org/jira/browse/JCRVLT-367
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.2.8
>Reporter: Robert Munteanu
>Priority: Minor
> Fix For: 3.4.0
>
> Attachments: JCRVLT-367-remove-version-parsing-v01.patch
>
>
> {noformat}$ vlt --version
> /usr/bin/vlt: line 146: [: 110 2019-07-16: integer expression expected
> Jackrabbit FileVault [version 3.2.8] Copyright 2018 by Apache Software
> Foundation. See LICENSE.txt for more information.{noformat}
> {noformat}$ java -version
> openjdk version "11.0.4" 2019-07-16
> OpenJDK Runtime Environment (build 11.0.4+11-suse-1.1-x8664)
> OpenJDK 64-Bit Server VM (build 11.0.4+11-suse-1.1-x8664, mixed
> mode){noformat}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (JCRVLT-367) CLONE - vlt shell script prints out error when using openjdk
[
https://issues.apache.org/jira/browse/JCRVLT-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16926196#comment-16926196
]
Tobias Bocanegra commented on JCRVLT-367:
-
I don't think we should block the release... moving it to 3.4.2
> CLONE - vlt shell script prints out error when using openjdk
>
>
> Key: JCRVLT-367
> URL: https://issues.apache.org/jira/browse/JCRVLT-367
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.2.8
>Reporter: Robert Munteanu
>Priority: Minor
> Fix For: 3.4.2
>
> Attachments: JCRVLT-367-remove-version-parsing-v01.patch
>
>
> {noformat}$ vlt --version
> /usr/bin/vlt: line 146: [: 110 2019-07-16: integer expression expected
> Jackrabbit FileVault [version 3.2.8] Copyright 2018 by Apache Software
> Foundation. See LICENSE.txt for more information.{noformat}
> {noformat}$ java -version
> openjdk version "11.0.4" 2019-07-16
> OpenJDK Runtime Environment (build 11.0.4+11-suse-1.1-x8664)
> OpenJDK 64-Bit Server VM (build 11.0.4+11-suse-1.1-x8664, mixed
> mode){noformat}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (JCRVLT-367) CLONE - vlt shell script prints out error when using openjdk
[
https://issues.apache.org/jira/browse/JCRVLT-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra updated JCRVLT-367:
Fix Version/s: (was: 3.4.0)
3.4.2
> CLONE - vlt shell script prints out error when using openjdk
>
>
> Key: JCRVLT-367
> URL: https://issues.apache.org/jira/browse/JCRVLT-367
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.2.8
>Reporter: Robert Munteanu
>Priority: Minor
> Fix For: 3.4.2
>
> Attachments: JCRVLT-367-remove-version-parsing-v01.patch
>
>
> {noformat}$ vlt --version
> /usr/bin/vlt: line 146: [: 110 2019-07-16: integer expression expected
> Jackrabbit FileVault [version 3.2.8] Copyright 2018 by Apache Software
> Foundation. See LICENSE.txt for more information.{noformat}
> {noformat}$ java -version
> openjdk version "11.0.4" 2019-07-16
> OpenJDK Runtime Environment (build 11.0.4+11-suse-1.1-x8664)
> OpenJDK 64-Bit Server VM (build 11.0.4+11-suse-1.1-x8664, mixed
> mode){noformat}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (JCRVLT-287) Throw exception in case of ACL Importer failures (instead of just logging)
[
https://issues.apache.org/jira/browse/JCRVLT-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16925399#comment-16925399
]
Tobias Bocanegra commented on JCRVLT-287:
-
bq. Do you think we should already add a new ImportOption to optionally fall
back to the old behaviour?
no, I don't think so.
> Throw exception in case of ACL Importer failures (instead of just logging)
> --
>
> Key: JCRVLT-287
> URL: https://issues.apache.org/jira/browse/JCRVLT-287
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: Packaging
>Affects Versions: 3.1.44
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.4.0
>
>
> Currently the {{JackrabbitACLImporter}} just logs any exception which occurs
> while trying to apply ACLs but this exception is not being propagated to the
> caller
> (https://github.com/apache/jackrabbit-filevault/blob/0dcf09d58fa40cbe3bc24dcb6a00281123bd5a1c/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/JackrabbitACLImporter.java#L160).
> The exception should basically bubble up till {{JcrPackage.install/extract}}
> as {{RepositoryException}}!
> {code}
> org.apache.jackrabbit.vault.fs.impl.io.DocViewSAXImporter Error while
> applying access control content.
> javax.jcr.AccessDeniedException: Access denied.
> at
> org.apache.jackrabbit.oak.spi.security.authorization.accesscontrol.AbstractAccessControlManager.checkPermissions(AbstractAccessControlManager.java:200)
> at
> org.apache.jackrabbit.oak.spi.security.authorization.accesscontrol.AbstractAccessControlManager.getTree(AbstractAccessControlManager.java:167)
> at
> org.apache.jackrabbit.oak.security.authorization.accesscontrol.AccessControlManagerImpl.setPolicy(AccessControlManagerImpl.java:219)
> at
> org.apache.jackrabbit.oak.security.authorization.composite.CompositeAccessControlManager.setPolicy(CompositeAccessControlManager.java:109)
> at
> org.apache.jackrabbit.oak.jcr.delegate.AccessControlManagerDelegator$8.performVoid(AccessControlManagerDelegator.java:132)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.performVoid(SessionDelegate.java:274)
> at
> org.apache.jackrabbit.oak.jcr.delegate.AccessControlManagerDelegator.setPolicy(AccessControlManagerDelegator.java:129)
> at
> org.apache.jackrabbit.oak.jcr.delegate.JackrabbitAccessControlManagerDelegator.setPolicy(JackrabbitAccessControlManagerDelegator.java:152)
> at
> org.apache.jackrabbit.vault.fs.impl.io.JackrabbitACLImporter$ImportedAcList.apply(JackrabbitACLImporter.java:318)
> at
> org.apache.jackrabbit.vault.fs.impl.io.JackrabbitACLImporter.close(JackrabbitACLImporter.java:158)
> at
> org.apache.jackrabbit.vault.fs.impl.io.DocViewSAXImporter.endElement(DocViewSAXImporter.java:1153)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:609)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1782)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2967)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:602)
> at
> com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:112)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:505)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:842)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:771)
> at
> com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1213)
> at
> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:643)
> at
> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.parse(SAXParserImpl.java:327)
> at
> org.apache.jackrabbit.vault.fs.impl.io.GenericArtifactHandler.accept(GenericArtifactHandler.java:99)
> at org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:879)
> at org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:784)
> at org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:824)
> at org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:824)
> at org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:824)
[jira] [Resolved] (JCRVLT-364) Upgrade jackrabbit and oak and use Java 8
[ https://issues.apache.org/jira/browse/JCRVLT-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Bocanegra resolved JCRVLT-364. - Resolution: Fixed fixed in https://svn.apache.org/viewvc?view=revision=1866639 > Upgrade jackrabbit and oak and use Java 8 > - > > Key: JCRVLT-364 > URL: https://issues.apache.org/jira/browse/JCRVLT-364 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: vlt >Reporter: Tobias Bocanegra >Assignee: Tobias Bocanegra >Priority: Major > Fix For: 3.2.10 > > > - use java 8 (in pom.xml) > - use jackrabbit 2.18.3 > - use oak 1.16.0 -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Assigned] (JCRVLT-364) Upgrade jackrabbit and oak and use Java 8
[ https://issues.apache.org/jira/browse/JCRVLT-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Bocanegra reassigned JCRVLT-364: --- Assignee: Tobias Bocanegra > Upgrade jackrabbit and oak and use Java 8 > - > > Key: JCRVLT-364 > URL: https://issues.apache.org/jira/browse/JCRVLT-364 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: vlt >Reporter: Tobias Bocanegra >Assignee: Tobias Bocanegra >Priority: Major > Fix For: 3.2.10 > > > - use java 8 (in pom.xml) > - use jackrabbit 2.18.3 > - use oak 1.16.0 -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Resolved] (JCRVLT-341) https doesn't work anymore
[
https://issues.apache.org/jira/browse/JCRVLT-341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra resolved JCRVLT-341.
-
Resolution: Fixed
fixed in
https://svn.apache.org/viewvc/jackrabbit/commons/filevault/trunk/parent/pom.xml?r1=1866638=1866637=1866638
[~ch00stw] please note, that the problem reported is fixed in jackrabbit
2.18.3, so in case you use the RCP service, it would be enough to update your
AEM instance to jackrabbit 2.18.3.
> https doesn't work anymore
> --
>
> Key: JCRVLT-341
> URL: https://issues.apache.org/jira/browse/JCRVLT-341
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: RCP, vlt
>Affects Versions: 3.1.44, 3.2.6, 3.2.8
> Environment: source instance is suse linux sles 12
> target instance is suse linux sles 12 and windows 10
> java 1.8
> AEM 6.4.4
>Reporter: WalterSteiner
>Assignee: Tobias Bocanegra
>Priority: Major
> Fix For: 3.2.10
>
>
> org.apache.jackrabbit.vault.rcp-3.1.24 introduced support of https. I now
> upgraded to the version 3.2.8. I want to transfer with the following path
> "/content/etc/robots.txt" from one aem-author instance to another. I get the
> following log entry
> 16.07.2019 10:52:52.827 *ERROR* [Vault RCP Task - copy-contentetcrobots.txt]
> org.apache.jackrabbit.vault.util.RepositoryCopier Error while retrieving src
> node /content/etc/robots.txt: javax.jcr.PathNotFoundException:
> /content/etc/robots.txt
> In the source, this path exists. If I do the same with http. The path is
> found and the content transfered.
> I use the following json to create the tast in aem
> {code}
> {
> "cmd":"create",
> "id":"copy-contentetcrobots.txt",
>
> "src":"https://user:password@host:port/crx/server/crx.default/jcr:root/content/etc/robots.txt;,
> "dst":"/content/etc/robots.txt",
> "batchsize": 2048,
> "update": true,
> "onlyNewer": true,
> "recursive": true,
> "throttle": 1,
> "excludes": []
> }
> {code}
> Please fix this issue, because we are no longer allowed to use http in our
> company.
>
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (JCRVLT-287) Throw exception in case of ACL Importer failures (instead of just logging)
[
https://issues.apache.org/jira/browse/JCRVLT-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16925266#comment-16925266
]
Tobias Bocanegra commented on JCRVLT-287:
-
I think this was deliberately not propagated, so that packages can be
installed, even if they have ACL content that cannot be installed with the
current user... but I think with modern content package usage patterns, this
might not be relevant anymore.
just be prepared to fix potential regression bugs :-)
> Throw exception in case of ACL Importer failures (instead of just logging)
> --
>
> Key: JCRVLT-287
> URL: https://issues.apache.org/jira/browse/JCRVLT-287
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: Packaging
>Affects Versions: 3.1.44
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.2.10
>
>
> Currently the {{JackrabbitACLImporter}} just logs any exception which occurs
> while trying to apply ACLs but this exception is not being propagated to the
> caller
> (https://github.com/apache/jackrabbit-filevault/blob/0dcf09d58fa40cbe3bc24dcb6a00281123bd5a1c/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/JackrabbitACLImporter.java#L160).
> The exception should basically bubble up till {{JcrPackage.install/extract}}
> as {{RepositoryException}}!
> {code}
> org.apache.jackrabbit.vault.fs.impl.io.DocViewSAXImporter Error while
> applying access control content.
> javax.jcr.AccessDeniedException: Access denied.
> at
> org.apache.jackrabbit.oak.spi.security.authorization.accesscontrol.AbstractAccessControlManager.checkPermissions(AbstractAccessControlManager.java:200)
> at
> org.apache.jackrabbit.oak.spi.security.authorization.accesscontrol.AbstractAccessControlManager.getTree(AbstractAccessControlManager.java:167)
> at
> org.apache.jackrabbit.oak.security.authorization.accesscontrol.AccessControlManagerImpl.setPolicy(AccessControlManagerImpl.java:219)
> at
> org.apache.jackrabbit.oak.security.authorization.composite.CompositeAccessControlManager.setPolicy(CompositeAccessControlManager.java:109)
> at
> org.apache.jackrabbit.oak.jcr.delegate.AccessControlManagerDelegator$8.performVoid(AccessControlManagerDelegator.java:132)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.performVoid(SessionDelegate.java:274)
> at
> org.apache.jackrabbit.oak.jcr.delegate.AccessControlManagerDelegator.setPolicy(AccessControlManagerDelegator.java:129)
> at
> org.apache.jackrabbit.oak.jcr.delegate.JackrabbitAccessControlManagerDelegator.setPolicy(JackrabbitAccessControlManagerDelegator.java:152)
> at
> org.apache.jackrabbit.vault.fs.impl.io.JackrabbitACLImporter$ImportedAcList.apply(JackrabbitACLImporter.java:318)
> at
> org.apache.jackrabbit.vault.fs.impl.io.JackrabbitACLImporter.close(JackrabbitACLImporter.java:158)
> at
> org.apache.jackrabbit.vault.fs.impl.io.DocViewSAXImporter.endElement(DocViewSAXImporter.java:1153)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:609)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1782)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2967)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:602)
> at
> com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:112)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:505)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:842)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:771)
> at
> com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1213)
> at
> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:643)
> at
> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.parse(SAXParserImpl.java:327)
> at
> org.apache.jackrabbit.vault.fs.impl.io.GenericArtifactHandler.accept(GenericArtifactHandler.java:99)
> at org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:879)
> at org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:784)
> at
[jira] [Created] (JCRVLT-364) Upgrade jackrabbit and oak and use Java 8
Tobias Bocanegra created JCRVLT-364: --- Summary: Upgrade jackrabbit and oak and use Java 8 Key: JCRVLT-364 URL: https://issues.apache.org/jira/browse/JCRVLT-364 Project: Jackrabbit FileVault Issue Type: Improvement Components: vlt Reporter: Tobias Bocanegra Fix For: 3.2.10 - use java 8 (in pom.xml) - use jackrabbit 2.18.3 - use oak 1.16.0 -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (JCRVLT-220) Include package type when assembling a package
[ https://issues.apache.org/jira/browse/JCRVLT-220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16923825#comment-16923825 ] Tobias Bocanegra commented on JCRVLT-220: - it is used to specify the type of content covered by that filter. ideally, a package should consist of one type. if the `content-package-type` is missing in the manifest, it is autodetected based on the filter roots. if a filter root is of type `cleanup` it is ignored for the type detection. (admittedly, this was a very specific addition to help 'moving' code in application packages from `/etc/` to `/libs`. hence the name 'cleanup') > Include package type when assembling a package > -- > > Key: JCRVLT-220 > URL: https://issues.apache.org/jira/browse/JCRVLT-220 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: Packaging >Affects Versions: 3.1.40 >Reporter: Tobias Bocanegra >Priority: Major > Fix For: 3.1.42 > > > Currently the package page can only be defined with external tools, but not > when assembling a package. > it should be possible to: > - specify the package type during build time > - have a automatic detection of the package type, based on content or filter. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Resolved] (JCRVLT-359) Provide separate option to control handling of rep:cugPolicy nodes.
[ https://issues.apache.org/jira/browse/JCRVLT-359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Bocanegra resolved JCRVLT-359. - Fix Version/s: 3.2.10 Resolution: Fixed fixed in r1866426 > Provide separate option to control handling of rep:cugPolicy nodes. > --- > > Key: JCRVLT-359 > URL: https://issues.apache.org/jira/browse/JCRVLT-359 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Affects Versions: 3.2.8 >Reporter: Alexei Krainiouk >Priority: Major > Fix For: 3.2.10 > > > Currently handling of rep:cugPolicy nodes is controlled by aclHandling > configuration option that equally affects ACLs and CUGs. We need to control > them separately as for replication that is based on sling-distribution we > need to ignore ACLs while overwriting CUGs -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (JCRVLT-341) https doesn't work anymore
[
https://issues.apache.org/jira/browse/JCRVLT-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16922947#comment-16922947
]
Tobias Bocanegra commented on JCRVLT-341:
-
you are correct. the Java 8 dependency is IMO only really relevant for the
vault-core osgi bundle. the jackrabbit spi dependency is only directly used in
the CLI and the RCP service. but the RCP service expects the jackrabbit-spi to
be present in the system already. so, we might be actually good :-) in this
case.
but if we add changes that require a new jackrabbit-api, that only come with a
jackrabbit/oak version that requires java 8, a customer might not be able to
upgrade, if he's stuck with java 7 (e.g. using IBM JDK).
> https doesn't work anymore
> --
>
> Key: JCRVLT-341
> URL: https://issues.apache.org/jira/browse/JCRVLT-341
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: RCP, vlt
>Affects Versions: 3.1.44, 3.2.6, 3.2.8
> Environment: source instance is suse linux sles 12
> target instance is suse linux sles 12 and windows 10
> java 1.8
> AEM 6.4.4
>Reporter: WalterSteiner
>Assignee: Tobias Bocanegra
>Priority: Major
> Fix For: 3.2.10
>
>
> org.apache.jackrabbit.vault.rcp-3.1.24 introduced support of https. I now
> upgraded to the version 3.2.8. I want to transfer with the following path
> "/content/etc/robots.txt" from one aem-author instance to another. I get the
> following log entry
> 16.07.2019 10:52:52.827 *ERROR* [Vault RCP Task - copy-contentetcrobots.txt]
> org.apache.jackrabbit.vault.util.RepositoryCopier Error while retrieving src
> node /content/etc/robots.txt: javax.jcr.PathNotFoundException:
> /content/etc/robots.txt
> In the source, this path exists. If I do the same with http. The path is
> found and the content transfered.
> I use the following json to create the tast in aem
> {code}
> {
> "cmd":"create",
> "id":"copy-contentetcrobots.txt",
>
> "src":"https://user:password@host:port/crx/server/crx.default/jcr:root/content/etc/robots.txt;,
> "dst":"/content/etc/robots.txt",
> "batchsize": 2048,
> "update": true,
> "onlyNewer": true,
> "recursive": true,
> "throttle": 1,
> "excludes": []
> }
> {code}
> Please fix this issue, because we are no longer allowed to use http in our
> company.
>
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (JCRVLT-341) https doesn't work anymore
[
https://issues.apache.org/jira/browse/JCRVLT-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16922301#comment-16922301
]
Tobias Bocanegra commented on JCRVLT-341:
-
I would branch off 3.2.x and start with 4.0.0 only supporting java 8.
and then only include jackrabbit 2.18 there.
> https doesn't work anymore
> --
>
> Key: JCRVLT-341
> URL: https://issues.apache.org/jira/browse/JCRVLT-341
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: RCP, vlt
>Affects Versions: 3.1.44, 3.2.6, 3.2.8
> Environment: source instance is suse linux sles 12
> target instance is suse linux sles 12 and windows 10
> java 1.8
> AEM 6.4.4
>Reporter: WalterSteiner
>Assignee: Tobias Bocanegra
>Priority: Major
> Fix For: 3.2.10
>
>
> org.apache.jackrabbit.vault.rcp-3.1.24 introduced support of https. I now
> upgraded to the version 3.2.8. I want to transfer with the following path
> "/content/etc/robots.txt" from one aem-author instance to another. I get the
> following log entry
> 16.07.2019 10:52:52.827 *ERROR* [Vault RCP Task - copy-contentetcrobots.txt]
> org.apache.jackrabbit.vault.util.RepositoryCopier Error while retrieving src
> node /content/etc/robots.txt: javax.jcr.PathNotFoundException:
> /content/etc/robots.txt
> In the source, this path exists. If I do the same with http. The path is
> found and the content transfered.
> I use the following json to create the tast in aem
> {code}
> {
> "cmd":"create",
> "id":"copy-contentetcrobots.txt",
>
> "src":"https://user:password@host:port/crx/server/crx.default/jcr:root/content/etc/robots.txt;,
> "dst":"/content/etc/robots.txt",
> "batchsize": 2048,
> "update": true,
> "onlyNewer": true,
> "recursive": true,
> "throttle": 1,
> "excludes": []
> }
> {code}
> Please fix this issue, because we are no longer allowed to use http in our
> company.
>
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (JCRVLT-359) Provide separate option to control handling of rep:cugPolicy nodes.
[ https://issues.apache.org/jira/browse/JCRVLT-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16921794#comment-16921794 ] Tobias Bocanegra commented on JCRVLT-359: - I think this is correct. > Provide separate option to control handling of rep:cugPolicy nodes. > --- > > Key: JCRVLT-359 > URL: https://issues.apache.org/jira/browse/JCRVLT-359 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Affects Versions: 3.2.8 >Reporter: Alexei Krainiouk >Priority: Major > > Currently handling of rep:cugPolicy nodes is controlled by aclHandling > configuration option that equally affects ACLs and CUGs. We need to control > them separately as for replication that is based on sling-distribution we > need to ignore ACLs while overwriting CUGs -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (JCRVLT-359) Provide separate option to control handling of rep:cugPolicy nodes.
[
https://issues.apache.org/jira/browse/JCRVLT-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16919044#comment-16919044
]
Tobias Bocanegra commented on JCRVLT-359:
-
I do not really understand the problem. AFAIK, the {{rep:cugPolicy}} are a
special kind of policy nodes, thus are related to ACL handing. if their
serialization is missing or wrong, this needs to be added to the special ACL
handling. /cc [~angela]
> Provide separate option to control handling of rep:cugPolicy nodes.
> ---
>
> Key: JCRVLT-359
> URL: https://issues.apache.org/jira/browse/JCRVLT-359
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Affects Versions: 3.2.8
>Reporter: Alexei Krainiouk
>Priority: Major
>
> Currently handling of rep:cugPolicy nodes is controlled by aclHandling
> configuration option that equally affects ACLs and CUGs. We need to control
> them separately as for replication that is based on sling-distribution we
> need to ignore ACLs while overwriting CUGs
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (JCRVLT-358) XmlAnalyser.analyze does not correctly detect regular (non FileVault) DocView xml
[
https://issues.apache.org/jira/browse/JCRVLT-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16919041#comment-16919041
]
Tobias Bocanegra commented on JCRVLT-358:
-
I think that we can explicitly not support regular docview (and sysview). I
don't think there is any benefit.
> XmlAnalyser.analyze does not correctly detect regular (non FileVault) DocView
> xml
> -
>
> Key: JCRVLT-358
> URL: https://issues.apache.org/jira/browse/JCRVLT-358
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Reporter: Konrad Windszus
>Priority: Major
>
> Only doc view files starting with element {{jcr:root}} are detected due to
> https://github.com/apache/jackrabbit-filevault/blob/2cf781d74fa18d86d061f9962c51f7470cac4096/vault-sync/src/main/java/org/apache/jackrabbit/vault/sync/impl/XmlAnalyzer.java#L83.
> But regular docview allows arbitrary elements according to
> https://docs.adobe.com/docs/en/spec/jcr/2.0/7_Export.html#7.3%20Document%20View
> (in contrast to the extended doc view from FileVault:
> https://jackrabbit.apache.org/filevault/docview.html). For regular docview
> files always {{SerializationType.XML_GENERIC}} is being returned.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (JCRVLT-357) Split up DocViewSaxImporter: Separate parsing from importing
[ https://issues.apache.org/jira/browse/JCRVLT-357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16916856#comment-16916856 ] Tobias Bocanegra commented on JCRVLT-357: - I agree that the importer can be optimized ;-) but it has grown over the last years to accommodate all special cases that came up, and is IMO a bit fragile to changes. I would be very scared to change much in that code. also, it must still support importing of very large trees, which do not fit into memory... > Split up DocViewSaxImporter: Separate parsing from importing > > > Key: JCRVLT-357 > URL: https://issues.apache.org/jira/browse/JCRVLT-357 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: vlt >Reporter: Konrad Windszus >Priority: Major > Fix For: 3.2.10 > > > To be able to reuse the logic from DocViewSaxImporter (e.g. in the context of > JCRVLT-345) the parsing part (i.e. deserializing into DocViewNodes) should be > separated from the actual import. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (JCRVLT-355) False error in case embedded file/subpackage is overwritten by jcrRootSourceDirectory
[
https://issues.apache.org/jira/browse/JCRVLT-355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16910565#comment-16910565
]
Tobias Bocanegra commented on JCRVLT-355:
-
iirc, the check tries to prevent problems when different filter roots and
modes
the problem in the 1st project is:
{code}
{code}
such as the {{/conf/myproject1/settings/wcm}} path is already covered by the
first root.
this one is better:
{code}
{code}
> False error in case embedded file/subpackage is overwritten by
> jcrRootSourceDirectory
> -
>
> Key: JCRVLT-355
> URL: https://issues.apache.org/jira/browse/JCRVLT-355
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.4
>Reporter: Stefan Seifert
>Assignee: Konrad Windszus
>Priority: Major
>
> i've found problem with the check introduced with JCRVLT-279 - or i do not
> understand why the check leads to a failure in my case.
> i've two projects where this happens:
> 1. conf-content:
> https://github.com/stefanseifert/filevault-package-maven-plugin-1.0.4-validation-issues/tree/master/content-packages/conf-content
> fails with:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.jackrabbit:filevault-package-maven-plugin:1.0.4:package
> (default-package) on project
> mycompany.myprojectgroup.myproject1.conf-content:
> org.apache.maven.plugin.MojoFailureException: Found duplicate files in
> content package, most probably you have overlapping filter roots or you embed
> a file which is already there in 'jcrRootSourceDirectory'. For details check
> the nested exception!: Duplicate file
> jcr_root\conf\myproject1\settings\wcm\policies was found and the duplicate
> attribute is 'fail'. {noformat}
> 2. ui.apps
> https://github.com/stefanseifert/filevault-package-maven-plugin-1.0.4-validation-issues/tree/master/content-packages/ui.apps
> fails with:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.jackrabbit:filevault-package-maven-plugin:1.0.4:package
> (default-package) on project mycompany.myprojectgroup.myproject1.ui.apps:
> org.apache.maven.plugin.MojoFailureException: Found duplicate files in
> content package, most probably you have overlapping filter roots or you embed
> a file which is already there in 'jcrRootSourceDirectory'. For details check
> the nested exception!: Duplicate file
> jcr_root\apps\epsilon65Project\clientlibs\.content.xml was found and the
> duplicate attribute is 'fail'.
> {noformat}
> the second project is a special case because in some files in the
> "clientlibs" folder placeholders are replaced using maven resource filtering,
> if the corresponding build-helper-maven-plugin definition is removed the
> build works.
> but the first project is really simple project.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (JCRVLT-355) False error in case embedded file/subpackage is overwritten by jcrRootSourceDirectory
[
https://issues.apache.org/jira/browse/JCRVLT-355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16910548#comment-16910548
]
Tobias Bocanegra commented on JCRVLT-355:
-
I think the problem comes from the files added to the resources via the
{{build-helper-maven-plugin}}. if comment this plugin, the error does not occur.
if you set the root directoy to vault-work, it works:
{code}
${project.build.directory}/vault-work
{code}
(don't know if it produces the correct result, though ;-)
> False error in case embedded file/subpackage is overwritten by
> jcrRootSourceDirectory
> -
>
> Key: JCRVLT-355
> URL: https://issues.apache.org/jira/browse/JCRVLT-355
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.4
>Reporter: Stefan Seifert
>Assignee: Konrad Windszus
>Priority: Major
>
> i've found problem with the check introduced with JCRVLT-279 - or i do not
> understand why the check leads to a failure in my case.
> i've two projects where this happens:
> 1. conf-content:
> https://github.com/stefanseifert/filevault-package-maven-plugin-1.0.4-validation-issues/tree/master/content-packages/conf-content
> fails with:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.jackrabbit:filevault-package-maven-plugin:1.0.4:package
> (default-package) on project
> mycompany.myprojectgroup.myproject1.conf-content:
> org.apache.maven.plugin.MojoFailureException: Found duplicate files in
> content package, most probably you have overlapping filter roots or you embed
> a file which is already there in 'jcrRootSourceDirectory'. For details check
> the nested exception!: Duplicate file
> jcr_root\conf\myproject1\settings\wcm\policies was found and the duplicate
> attribute is 'fail'. {noformat}
> 2. ui.apps
> https://github.com/stefanseifert/filevault-package-maven-plugin-1.0.4-validation-issues/tree/master/content-packages/ui.apps
> fails with:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.jackrabbit:filevault-package-maven-plugin:1.0.4:package
> (default-package) on project mycompany.myprojectgroup.myproject1.ui.apps:
> org.apache.maven.plugin.MojoFailureException: Found duplicate files in
> content package, most probably you have overlapping filter roots or you embed
> a file which is already there in 'jcrRootSourceDirectory'. For details check
> the nested exception!: Duplicate file
> jcr_root\apps\epsilon65Project\clientlibs\.content.xml was found and the
> duplicate attribute is 'fail'.
> {noformat}
> the second project is a special case because in some files in the
> "clientlibs" folder placeholders are replaced using maven resource filtering,
> if the corresponding build-helper-maven-plugin definition is removed the
> build works.
> but the first project is really simple project.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (JCRVLT-354) False warnings for files not being included in the package due to being outside of filter roots
[
https://issues.apache.org/jira/browse/JCRVLT-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16910528#comment-16910528
]
Tobias Bocanegra commented on JCRVLT-354:
-
maybe it's a windows specific problem
> False warnings for files not being included in the package due to being
> outside of filter roots
> ---
>
> Key: JCRVLT-354
> URL: https://issues.apache.org/jira/browse/JCRVLT-354
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.4
>Reporter: Stefan Seifert
>Assignee: Konrad Windszus
>Priority: Major
>
> the new check introduced in JCRVLT-321 produces false warnings in my case -
> or i do not understand why the warning occurs.
> here is a sample project:
> https://github.com/stefanseifert/filevault-package-maven-plugin-1.0.4-validation-issues/tree/master/content-packages/sample-content
> i can understand these warnings
> {noformat}
> [WARNING] File content-packages\sample-content\jcr_root\.content.xml not
> covered by a filter rule and therefore not contained in the resulting package
> [WARNING] File content-packages\sample-content\jcr_root\content\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\.content.xml not covered
> by a filter rule and therefore not contained in the resulting package
> {noformat}
> although it's a pity they are reported because usually these .content.xml
> files "above" the filter paths help creating in between nodes when the
> package is extracted and the parent paths of the filter do not exist yet.
> but i do not understand these warnings as the files are definitely included
> in the filter:
> {noformat}
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg.dir\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\_jcr_content\renditions\original
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\chicago.jpg\_jcr_content\renditions\original.dir\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg.dir\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\_jcr_content\renditions\original
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\nature.jpg\_jcr_content\renditions\original.dir\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\prague.jpg\.content.xml
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
> content-packages\sample-content\jcr_root\content\dam\myproject1\prague.jpg\_jcr_content\renditions\cq5dam.web.1280.1280.jpeg
> not covered by a filter rule and therefore not contained in the resulting
> package
> [WARNING] File
>
[jira] [Commented] (JCRVLT-120) Allow to filter content properties based on property name and value
[
https://issues.apache.org/jira/browse/JCRVLT-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16907459#comment-16907459
]
Tobias Bocanegra commented on JCRVLT-120:
-
it's a). it should behave consistently. excluded properties are neither removed
or updated, if they are not present in the package.
so the example:
{code}
{code}
it should not remove the {{cq:lastReplicated}} of existing content.
> Allow to filter content properties based on property name and value
>
>
> Key: JCRVLT-120
> URL: https://issues.apache.org/jira/browse/JCRVLT-120
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: vlt
>Affects Versions: 3.1.26
>Reporter: Timothee Maret
>Priority: Major
> Fix For: 3.1.28
>
> Attachments: JCRVLT-120.patch, JCRVLT-120.patch, JCRVLT-120.patch
>
>
> In our use case, we need to filter content distributed by filevault for
> properties {{cq:lastReplicated}}, {{cq:lastReplicatedBy}} and
> {{cq:lastReplicationAction}}.
> This feature could cover more than those three property and instead be
> generalised to filter any property which name and value match the configured
> filter.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
