[
https://issues.apache.org/jira/browse/SLING-9623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176331#comment-17176331
]
Angela Schreiber commented on SLING-9623:
-----------------------------------------
[~rombert], i had a closer look at the implementation of {{ResourceMapper}} to
see if i can spot what would need to change in order to satisfy the tests. here
my initial findings:
- {{loadAliasIfApplicable}} needs return a {{Collection}} instead of a single
{{String}}
- consequently {{populateMappingsFromMapEntries}} needs a {{Collection<String>
mappedPaths}} param instead of {{String mappedPath}} => populate for all
mappedPaths instead of just for a single one
inside {{loadAliasIfApplicable}}:
- the local field {{names}} cannot be a {{LinkedList<String>}}, because there
might be multiple aliases and the full set of alias combinations also needs to
take the 'regular' name into account
- the local field {{alias}} consequently also needs to be some sort of
collection
- for the {{optimizedAliasResolutionEnabled}} case it's might be sufficient to
remove the {{break}} in order to get all the alias values (as far as i could
see {{MapEntries}} already expects _sling:alias_ to be multivalued)
- in the non-optimized case: get prop-values as collection/string-array instead
of just a single string.
- {{ResourceUtil.getName(path)}} IMHO always needs to be added to the list of
aliases in order to be able to compute all paths-variants
- finally: with {{names}} no longer being a simple list, the computation of the
paths get's more complex since all combinations need to be generated.... i
wonder if it might be better to choose a different approach here instead of
just replace {{LinkedList<String>}}} by {{LinkedList<Collection<String>>}}
- _note_: if the regular resource name gets added to the alias list to compute
all variants, it may lead to the resource path ends up being duplicated in the
final mappings, which are a list not a set... so some extra handling needed to
avoid that (e.g. omitting it from collection of aliases)
some of the modifications outlined are probably already part of SLING-9622.
hope that helps.
> ResourceMapperImpl.getAllMappings is incomplete for nested alias
> ----------------------------------------------------------------
>
> Key: SLING-9623
> URL: https://issues.apache.org/jira/browse/SLING-9623
> Project: Sling
> Issue Type: Bug
> Components: ResourceResolver
> Affects Versions: Resource Resolver 1.6.16
> Reporter: Angela Schreiber
> Assignee: Robert Munteanu
> Priority: Major
> Fix For: Resource Resolver 1.6.18
>
> Attachments: SLING-9623-test.patch
>
>
> while investigating an issue involving {{sling:alias}}, i inadvertently
> created nested alias i.e. ended up having an alias define for the parent and
> a child page.
> when looking at the values obtained from {{ResourceMapper.getAllMappings}}, i
> noticed that it only contains 1 combination. cross-checking however revealed
> that all combinations define valid paths that are properly resolved by sling.
> h5. Example
> parent: _/parent_ with alias name 'alias-parent'
> child: _/parent/child_ with alias name 'alias-child'
> valid paths for the child are (and expected from
> {{ResourceMapper.getAllMappings}}):
> - _/parent/child_
> - _/parent/alias-child_
> - _/alias-parent/alias-child_
> - _/alias-parent/child_
> actual values obtained from {{ResourceMapper.getAllMappings}}:
> - _/parent/child_
> - _/alias-parent/alias-child_
> consequently, an consumer of {{ResourceMapper.getAllMappings}} will miss
> valid alias path mappings. with additional nesting or addition of multiple
> alias values (see SLING-9620), the number of missed paths will increase.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
