[jira] [Created] (JCRVLT-827) Determination of ImportMode dependent on order of filters in filter.xml

["Bart Thierens (Jira)" <ji...@apache.org>]

Bart Thierens created JCRVLT-827:
------------------------------------

             Summary: Determination of ImportMode dependent on order of filters in filter.xml
                 Key: JCRVLT-827
                 URL: https://issues.apache.org/jira/browse/JCRVLT-827
             Project: Jackrabbit FileVault
          Issue Type: Bug
          Components: vlt
    Affects Versions: 3.8.4
            Reporter: Bart Thierens


I noticed weird behaviour in the processing of the filters in filter.xml that does not seem to be documented explicitly in the [FileVault filter documentation|https://jackrabbit.apache.org/filevault/filter.html].

Consider this scenario:
{code:xml}
<filter root="/apps/my-app" mode="update_properties"/>
<filter root="/apps/my-app/components"/>
{code}

After renaming a node a few levels under /apps/my-app/components in my IDE (=making a change in the .content.xml) and installing the package, the new node (with the new name) appears, but the old one is *not deleted*. 
This seems weird because the most specific filter has the _implicit_ replace import mode.

When swapping the order of the filters it works correctly.
{code:xml}
<filter root="/apps/my-app/components"/>
<filter root="/apps/my-app" mode="update_properties"/>
{code}
This leads me to believe that the first match in the filter.xml is taken, ands not the most specific one. 
This also seems rather unfortunate in case someone would add a filter at the start of the filter.xml
{code:xml}
<filter root="/apps" mode="update_properties"/>
{code}
then ALL nodes under /apps will be update_properties regardless of any subsequent filters.

We have this scenario to guarantee certain parent folders are created with a certain node type instead of nt:folder. This is not guaranteed when switching the order of the filter statements.

I logged this as a bug but I'm more looking for info on the details of the workings of these filters.  Is this the expected behaviour? How should this problem be tackled then?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)