[
https://issues.apache.org/jira/browse/JCRVLT-845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated JCRVLT-845:
-----------------------------------
Summary: jackrabbit-filter validator does not evaluate filter.xml in the
same way that the importer does (only consider first matching root) (was:
filevault-package:validate-package does not evaluate filter.xml in the same way
that the importer does (only consider first matching root))
> jackrabbit-filter validator does not evaluate filter.xml in the same way that
> the importer does (only consider first matching root)
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: JCRVLT-845
> URL: https://issues.apache.org/jira/browse/JCRVLT-845
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: validation
> Affects Versions: 4.3.0
> Reporter: Santiago García Pimentel
> Assignee: Konrad Windszus
> Priority: Major
>
> I recently stumbled upon the issue that filevault finds the first filter that
> matches the root instead of finding the closest one
> (https://issues.apache.org/jira/browse/JCRVLT-96)
> still. when this happens, the validator not mark as not covered nodes on
> those circumstances.
> e.g. for these filter entries:
> {quote}<filter root="/conf/app" mode="merge_properties">
> <exclude pattern="/conf/app/settings/conf1(/.*)?"/>
> </filter>
> <filter root="/conf/app/settings/conf1" mode="replace"/>
> {quote}
> Due to JCRVLT-96 any content below conf1 will actually be excluded from
> installation (since it picked the first one, which excludes it) but the
> validator will not mark it as not covered by a filter this since a second
> filter (which actually never applies) exists.
> if the behavior described in JCRVLT-96 does not change (which after 10 years
> it probably wont) the validator should at least behave consistently.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
