[
https://issues.apache.org/jira/browse/SLING-10760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17405809#comment-17405809
]
Angela Schreiber commented on SLING-10760:
------------------------------------------
hi [~kwin] thanks for the insight. as you probably suspected I tested the
import with AEM. so, if AEM were to update to the latest version of Jackrabbit
FileVault the workaround for
siblings-in-dot-content.xml-but-not-covered-by-workspace-filter would no longer
be required because content packages relying on that behavior would anyway no
longer work, right? i will add more comments to the patch for SLING-10760 for
future reference/maintenance.
as far as JCRVLT-522 is concerned: this is exactly what this ticket here refers
to. based on your comments here and in the corresponding JCRVLT issue, it seems
that we likely need some major refactoring of the feature-cpconverter to make
sure all access control content is properly handled. do you know if it would
also apply to user/group nodes?
cc: [~karlpauls]
> Converter ignores access control content in .content.xml files
> --------------------------------------------------------------
>
> Key: SLING-10760
> URL: https://issues.apache.org/jira/browse/SLING-10760
> Project: Sling
> Issue Type: Bug
> Components: Content-Package to Feature Model Converter
> Reporter: Angela Schreiber
> Priority: Major
> Attachments: subtree_in_contentxml_policy.png,
> subtree_in_contentxml_sibling.png
>
>
> [~kpauls], while trying to find more edge cases that could cause SLING-10754,
> i noticed that not only sibling nodes but also access control content (like
> e.g. _rep:policy_ nodes) contained in a _.content.xml_ get installed by
> Jackrabbit Filevault even if those nodes are not covered by the corresponding
> {{WorkspaceFilter}}.
> It also seems that these package 'entries' are not spotted by the converter
> and thus the dedicated {{EntryHandler}} implementations that are intended to
> analyze and convert special content like e.g. access control (but probably
> not limited to that) are not triggered.
> In other words: content hidden in _.content.xml_ will not be properly
> converted but will be installed even if not covered by _filter.xml_
> associated with the content package. I don't know if that actually intended
> behavior of Jackrabbit FileVault (the documentation clearly stating that
> everything should be covered by filter rules [0], section 'Usage for
> Import/Installation'), but if it is correct it might in the worse case
> require the converter to parse all _.content.xml_ files and delegate to the
> proper handler implementations.
> [~kwin], I would appreciate your input on the FileVault related question of
> this ticket. In particular: is it correct and intended that subnodes defined
> in _.content.xml_ get installed even if not covered by any filter rule?
> [0] https://jackrabbit.apache.org/filevault/filter.html
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
