[
https://issues.apache.org/jira/browse/JCRVLT-830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated JCRVLT-830:
-----------------------------------
Description:
We have a situation, where content needed to be updated using filevault, but it
actually deleted content. We were able to reproduce this and found it to be
caused by the structure of the content package.
Context: We have identified this issue with AEM CS in the context of
replication, which uses filevault to both create and import the content package.
How to reproduce:
* Create a content structure {{/content/dam/qcom/content-fragments/en/test1}}
and create an additional sibling node {{"abc"}}. Use the nodetype
"sling:Folder" for these nodes.
* Install the content package
[^dstrpck-1763695579150-81d5fe51-b017-4dc8-a882-d01da5a3c003-fails.zip]
(mode=REPLACE, which is the default with the AEM package manager, and also used
in our usecase). You will get this output from filevault:
{noformat}
Importing content...
- /
- /content
- /content/dam
- /content/dam/qcom
- /content/dam/qcom/content-fragments
D /content/dam/qcom/content-fragments/en/test1
A /content/dam/qcom/content-fragments/en/test1
A /content/dam/qcom/content-fragments/en/test1/jcr:content
saving approx 3 nodes...
{noformat}
* Now when checking you will find that the node "abc" was deleted as well. But
given the overall structure of the content package this is not what we have
expected. It was our expectation that the node "abc" still exists.
We dug deeper and experimented a bit. When you redo the same steps with the
package
[^dstrpck-1763695579150-81d5fe51-b017-4dc8-a882-d01da5a3c003-fixed.zip] the
node abc still exists after the import.
The only difference between these content package is in the "fails" case the
structure in the content package looks like this:
{noformat}
jcr_root/content/dam/qcom/content-fragments/
jcr_root/content/dam/qcom/content-fragments/en/
jcr_root/content/dam/qcom/content-fragments/en/test1/
jcr_root/content/dam/qcom/content-fragments/en/test1/.content.xml
jcr_root/content/dam/qcom/content-fragments/en/test1/_jcr_content/
jcr_root/content/dam/qcom/content-fragments/en/test1/_jcr_content/.content.xml
jcr_root/content/dam/qcom/content-fragments/.content.xml
{noformat}
while in the "fixed" case it looks like this:
{noformat}
jcr_root/content/dam/qcom/content-fragments/
jcr_root/content/dam/qcom/content-fragments/en/
jcr_root/content/dam/qcom/content-fragments/en/test1/
jcr_root/content/dam/qcom/content-fragments/en/test1/.content.xml
jcr_root/content/dam/qcom/content-fragments/en/test1/_jcr_content/
jcr_root/content/dam/qcom/content-fragments/en/test1/_jcr_content/.content.xml
jcr_root/content/dam/qcom/content-fragments/.content.xml
jcr_root/content/dam/qcom/content-fragments/en/.content.xml
{noformat}
we split {{jcr_root/content/dam/qcom/content-fragments/.content.xml}} into the
2 files {{jcr_root/content/dam/qcom/content-fragments/.content.xml}} and
{{jcr_root/content/dam/qcom/content-fragments/en/.content.xml}}, all other
files are identical.
Now the questions:
* Is this expected behaviour? I am not sure, in my opinion the aggregation of
the node definitions into different files should not play a role here.
* The "failed" file was created by filevault directly, and I would like to
understand how filevault does the decision to either consolidate multiple nodes
into a single .content.xml file or to split them, so each node gets its own
.content.xml.
was:
We have a situation, where content needed to be updated using filevault, but it
actually deleted content. We were able to reproduce this and found it to be
caused by the structure of the content package.
Context: We have identified this issue with AEM CS in the context of
replication, which uses filevault to both create and import the content package.
How to reproduce:
* Create a content structure /content/dam/qcom/content-fragments/en/test1 and
create an additional node "abc". Use the nodetype "sling:Folder" for these
nodes.
* Install the content package
[^dstrpck-1763695579150-81d5fe51-b017-4dc8-a882-d01da5a3c003-fails.zip]
(mode=REPLACE, which is the default with the AEM package manager, and also used
in our usecase). You will get this output from filevault:
{noformat}
Importing content...
- /
- /content
- /content/dam
- /content/dam/qcom
- /content/dam/qcom/content-fragments
D /content/dam/qcom/content-fragments/en/test1
A /content/dam/qcom/content-fragments/en/test1
A /content/dam/qcom/content-fragments/en/test1/jcr:content
saving approx 3 nodes...
{noformat}
* Now when checking you will find that the node "abc" was deleted as well. But
given the overall structure of the content package this is not what we have
expected. It was our expectation that the node "abc" still exists.
We dug deeper and experimented a bit. When you redo the same steps with the
package
[^dstrpck-1763695579150-81d5fe51-b017-4dc8-a882-d01da5a3c003-fixed.zip] the
node abc still exists after the import.
The only difference between these content package is in the "fails" case the
structure in the content package looks like this:
{noformat}
jcr_root/content/dam/qcom/content-fragments/
jcr_root/content/dam/qcom/content-fragments/en/
jcr_root/content/dam/qcom/content-fragments/en/test1/
jcr_root/content/dam/qcom/content-fragments/en/test1/.content.xml
jcr_root/content/dam/qcom/content-fragments/en/test1/_jcr_content/
jcr_root/content/dam/qcom/content-fragments/en/test1/_jcr_content/.content.xml
jcr_root/content/dam/qcom/content-fragments/.content.xml
{noformat}
while in the "fixed" case it looks like this:
{noformat}
jcr_root/content/dam/qcom/content-fragments/
jcr_root/content/dam/qcom/content-fragments/en/
jcr_root/content/dam/qcom/content-fragments/en/test1/
jcr_root/content/dam/qcom/content-fragments/en/test1/.content.xml
jcr_root/content/dam/qcom/content-fragments/en/test1/_jcr_content/
jcr_root/content/dam/qcom/content-fragments/en/test1/_jcr_content/.content.xml
jcr_root/content/dam/qcom/content-fragments/.content.xml
jcr_root/content/dam/qcom/content-fragments/en/.content.xml
{noformat}
we split {{jcr_root/content/dam/qcom/content-fragments/.content.xml}} into the
2 files {{jcr_root/content/dam/qcom/content-fragments/.content.xml}} and
{{jcr_root/content/dam/qcom/content-fragments/en/.content.xml}}, all other
files are identical.
Now the questions:
* Is this expected behaviour? I am not sure, in my opinion the aggregation of
the node definitions into different files should not play a role here.
* The "failed" file was created by filevault directly, and I would like to
understand how filevault does the decision to either consolidate multiple nodes
into a single .content.xml file or to split them, so each node gets its own
.content.xml.
> "incorrect aggregatoin" can lead to the deletion of content
> -----------------------------------------------------------
>
> Key: JCRVLT-830
> URL: https://issues.apache.org/jira/browse/JCRVLT-830
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Affects Versions: 4.1.4
> Reporter: Joerg Hoh
> Priority: Major
> Attachments:
> dstrpck-1763695579150-81d5fe51-b017-4dc8-a882-d01da5a3c003-fails.zip,
> dstrpck-1763695579150-81d5fe51-b017-4dc8-a882-d01da5a3c003-fixed.zip
>
>
> We have a situation, where content needed to be updated using filevault, but
> it actually deleted content. We were able to reproduce this and found it to
> be caused by the structure of the content package.
> Context: We have identified this issue with AEM CS in the context of
> replication, which uses filevault to both create and import the content
> package.
> How to reproduce:
> * Create a content structure {{/content/dam/qcom/content-fragments/en/test1}}
> and create an additional sibling node {{"abc"}}. Use the nodetype
> "sling:Folder" for these nodes.
> * Install the content package
> [^dstrpck-1763695579150-81d5fe51-b017-4dc8-a882-d01da5a3c003-fails.zip]
> (mode=REPLACE, which is the default with the AEM package manager, and also
> used in our usecase). You will get this output from filevault:
> {noformat}
> Importing content...
> - /
> - /content
> - /content/dam
> - /content/dam/qcom
> - /content/dam/qcom/content-fragments
> D /content/dam/qcom/content-fragments/en/test1
> A /content/dam/qcom/content-fragments/en/test1
> A /content/dam/qcom/content-fragments/en/test1/jcr:content
> saving approx 3 nodes...
> {noformat}
> * Now when checking you will find that the node "abc" was deleted as well.
> But given the overall structure of the content package this is not what we
> have expected. It was our expectation that the node "abc" still exists.
> We dug deeper and experimented a bit. When you redo the same steps with the
> package
> [^dstrpck-1763695579150-81d5fe51-b017-4dc8-a882-d01da5a3c003-fixed.zip] the
> node abc still exists after the import.
> The only difference between these content package is in the "fails" case the
> structure in the content package looks like this:
> {noformat}
> jcr_root/content/dam/qcom/content-fragments/
> jcr_root/content/dam/qcom/content-fragments/en/
> jcr_root/content/dam/qcom/content-fragments/en/test1/
> jcr_root/content/dam/qcom/content-fragments/en/test1/.content.xml
> jcr_root/content/dam/qcom/content-fragments/en/test1/_jcr_content/
> jcr_root/content/dam/qcom/content-fragments/en/test1/_jcr_content/.content.xml
> jcr_root/content/dam/qcom/content-fragments/.content.xml
> {noformat}
> while in the "fixed" case it looks like this:
> {noformat}
> jcr_root/content/dam/qcom/content-fragments/
> jcr_root/content/dam/qcom/content-fragments/en/
> jcr_root/content/dam/qcom/content-fragments/en/test1/
> jcr_root/content/dam/qcom/content-fragments/en/test1/.content.xml
> jcr_root/content/dam/qcom/content-fragments/en/test1/_jcr_content/
> jcr_root/content/dam/qcom/content-fragments/en/test1/_jcr_content/.content.xml
> jcr_root/content/dam/qcom/content-fragments/.content.xml
> jcr_root/content/dam/qcom/content-fragments/en/.content.xml
> {noformat}
> we split {{jcr_root/content/dam/qcom/content-fragments/.content.xml}} into
> the 2 files {{jcr_root/content/dam/qcom/content-fragments/.content.xml}} and
> {{jcr_root/content/dam/qcom/content-fragments/en/.content.xml}}, all other
> files are identical.
> Now the questions:
> * Is this expected behaviour? I am not sure, in my opinion the aggregation of
> the node definitions into different files should not play a role here.
> * The "failed" file was created by filevault directly, and I would like to
> understand how filevault does the decision to either consolidate multiple
> nodes into a single .content.xml file or to split them, so each node gets its
> own .content.xml.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
