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

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

     [ https://issues.apache.org/jira/browse/JCRVLT-827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bart Thierens updated JCRVLT-827:
---------------------------------
    Description: 
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, and 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 handled using 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?

  was:
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, and 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?


> 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
>            Priority: Major
>
> 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, and 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 handled using 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)