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)
