[
https://issues.apache.org/jira/browse/SLING-10481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17360971#comment-17360971
]
Konrad Windszus edited comment on SLING-10481 at 6/10/21, 2:33 PM:
-------------------------------------------------------------------
There are two different ways on how to create {{VaultPackageAssembler}}:
# From an existing package taking over its filter
(https://github.com/apache/sling-org-apache-sling-feature-cpconverter/blob/e1ef2603085f08a777f89e6944bfc08b4585866d/src/main/java/org/apache/sling/feature/cpconverter/vltpkg/VaultPackageAssembler.java#L98)
and only removing potentially filter rules for bundles
(https://github.com/apache/sling-org-apache-sling-feature-cpconverter/blob/e1ef2603085f08a777f89e6944bfc08b4585866d/src/main/java/org/apache/sling/feature/cpconverter/vltpkg/VaultPackageAssembler.java#L225)
# From scratch
(https://github.com/apache/sling-org-apache-sling-feature-cpconverter/blob/e1ef2603085f08a777f89e6944bfc08b4585866d/src/main/java/org/apache/sling/feature/cpconverter/vltpkg/VaultPackageAssembler.java#L146).
The second approach is used for initial content packages, which create the
filters via
https://github.com/apache/sling-org-apache-sling-feature-cpconverter/blob/e1ef2603085f08a777f89e6944bfc08b4585866d/src/main/java/org/apache/sling/feature/cpconverter/handlers/BundleEntryHandler.java#L412
{{computeFilters()}} currently only adds new filters, but never touches
existing ones
(https://github.com/apache/sling-org-apache-sling-feature-cpconverter/blob/e1ef2603085f08a777f89e6944bfc08b4585866d/src/main/java/org/apache/sling/feature/cpconverter/vltpkg/VaultPackageAssembler.java#L400).
Not sure if this ever worked but for sure it was used prior to
https://github.com/apache/sling-org-apache-sling-feature-cpconverter/pull/74/commits/8f045881ea0f2fa45137d7022f4deb5282e164c3.
So this probably unveiled the issue.
Initially existing packages have only been stripped mainly by bundles, so the
simple logic in 1. was probably enough. It seems now even "application" type
content packages are stripped in a way that just removing the OSGi bundle
related filter is not enough. The logic in {{computeFilters}} for sure is not
enough, as it may miss important settings from the original package like
https://jackrabbit.apache.org/filevault/filter.html#Property_Filtering or just
simple {{exclude}} s, so if you really need to regenerate filters for stripped
"content" and "application" packages you need to be more careful.
was (Author: kwin):
There are two different ways on how to create {{VaultPackageAssembler}}:
1. From an existing package taking over its filter
(https://github.com/apache/sling-org-apache-sling-feature-cpconverter/blob/e1ef2603085f08a777f89e6944bfc08b4585866d/src/main/java/org/apache/sling/feature/cpconverter/vltpkg/VaultPackageAssembler.java#L98)
and only removing potentially filter rules for bundles
(https://github.com/apache/sling-org-apache-sling-feature-cpconverter/blob/e1ef2603085f08a777f89e6944bfc08b4585866d/src/main/java/org/apache/sling/feature/cpconverter/vltpkg/VaultPackageAssembler.java#L225)
1. From scratch
(https://github.com/apache/sling-org-apache-sling-feature-cpconverter/blob/e1ef2603085f08a777f89e6944bfc08b4585866d/src/main/java/org/apache/sling/feature/cpconverter/vltpkg/VaultPackageAssembler.java#L146).
The second approach is used for initial content packages, which create the
filters via
https://github.com/apache/sling-org-apache-sling-feature-cpconverter/blob/e1ef2603085f08a777f89e6944bfc08b4585866d/src/main/java/org/apache/sling/feature/cpconverter/handlers/BundleEntryHandler.java#L412
{{computeFilters()}} currently only adds new filters, but never touches
existing ones
(https://github.com/apache/sling-org-apache-sling-feature-cpconverter/blob/e1ef2603085f08a777f89e6944bfc08b4585866d/src/main/java/org/apache/sling/feature/cpconverter/vltpkg/VaultPackageAssembler.java#L400).
Not sure if this ever worked but for sure it was used prior to
https://github.com/apache/sling-org-apache-sling-feature-cpconverter/pull/74/commits/8f045881ea0f2fa45137d7022f4deb5282e164c3.
So this probably unveiled the issue.
Initially existing packages have only been stripped mainly by bundles, so the
simple logic in 1. was probably enough. It seems now even "application" type
content packages are stripped in a way that just removing the OSGi bundle
related filter is not enough. The logic in {{computeFilters}} for sure is not
enough, as it may miss important settings from the original package like
https://jackrabbit.apache.org/filevault/filter.html#Property_Filtering or just
simple {{exclude}} s, so if you really need to regenerate filters for stripped
"content" and "application" packages you need to be more careful.
> Review filter.xml creation for content package output of converter
> ------------------------------------------------------------------
>
> Key: SLING-10481
> URL: https://issues.apache.org/jira/browse/SLING-10481
> Project: Sling
> Issue Type: Improvement
> Components: Content-Package to Feature Model Converter
> Affects Versions: Content-Package to Feature Model Converter 1.1.4
> Reporter: Karl Pauls
> Priority: Major
> Fix For: Content-Package to Feature Model Converter 1.1.6
>
>
> The converter used to recalculate the filters for content-packages. Starting
> with SLING-10243 that was made optional (maybe to not do it for sling initial
> content packages) - however, it looks like it is now not done at all anymore.
> We have to see if that is what we want and if the filters are still correct
> for the converted packages (especially in the context of the principal and
> acl work).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
