[
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)
