[
https://issues.apache.org/jira/browse/SLING-10150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henry Kuijpers updated SLING-10150:
-----------------------------------
Description:
Provided a failing test case here:
https://github.com/apache/sling-org-apache-sling-resourcemerger/pull/3/files
TODO: Fix
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.
was:
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.
> 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
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Provided a failing test case here:
> https://github.com/apache/sling-org-apache-sling-resourcemerger/pull/3/files
> TODO: Fix
> 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)
