[ 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:32 PM: ------------------------------------------------------------------- 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. 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)