Henry Kuijpers created SLING-10150:
--------------------------------------
Summary: Sling Resource Merger completely hides parent when
whitelisting in combination with asterisk is used for sling:hideChildren
Key: SLING-10150
URL: https://issues.apache.org/jira/browse/SLING-10150
Project: Sling
Issue Type: Bug
Affects Versions: Resource Merger 1.3.10
Reporter: Henry Kuijpers
When trying to configure a whitelisting approach to inheriting nodes from a
parent (i.e. through resource super type, or through overlaying), the following
way:
/apps/base/test/tabs/undesired-tab
/apps/base/test/tabs/desired-tab
/apps/base/test/tabs/desired-tab/items/field@title="title"
&
/apps/overlay/test/tabs@sling:hideChildren="[!desired-tab,*]"
/apps/overlay/test/tabs/desired-tab/items/field@description="test"
One would expect that requesting the children of /merged/test/tabs would yield
the "desired-tab" only, i.e. "undesired-tab" (and other nodes not whitelisted)
being hidden. This is working as expected.
One would also expect the "desired-tab" to have the properties of the
base-structure as well as the properties of the overlay-structure. This is also
working as expected.
One would expect that the underlying nodes of "desired-tab" from the base would
remain intact and would be merged with the underlying nodes of "desired-tab" in
the overlay. So, while listing the items of desired-tab, one would expect:
MergedResource containing properties [title=test, description=test] consisting
of original resources [/apps/base/test/tabs/desired-tab/items/field,
/apps/overlay/test/tabs/desired-tab/items/field]
However, instead, the following is returned:
MergedResource containing properties [description=test] consisting of original
resources [/apps/overlay/test/tabs/desired-tab/items/field]
So, the original "base" resource is not considered anymore!
I believe the issue is in MergingResourceProvider.ParentHidingHandler, in the
constructor, actually. At some point, it decides that the parent resource
(which indeed has the sling:hideChildren property defined) defines an exclude
entry which is "*" and adds that entry to the list.
Then, when the class starts checking the parent of the parent (marked with "//
also check on the parent's parent whether that was hiding the parent") - There
it will find that asterisk exclude that was defined on the parent, not taking
into account that it was preceded by a whitelisting "!desired-tab" - Removing
the parent of the parent's children entirely.
I believe this should be changed into a more robust way of handling this
use-case. Probably the asterisk exclude can be global(?), even though it should
still be desired that any child of the parent still is able to remove that
exclude. But whenever those excludes are considered, also the includes that
were preceding it should be considered to figure out if it's a real include in
the case of that specific path.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
