[
https://issues.apache.org/jira/browse/SLING-4340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14286766#comment-14286766
]
Justin Edelson commented on SLING-4340:
---------------------------------------
bq. Looking at your use case: you have resource a1 with a resource type of
"nt:unstructed", a resource super type of "a2" and a2 has the resource type
foo/bar - now you're requesting the merged a1 resource. Which resource type
does it have? I would assume the one from the lowest resource in the tree which
is a1. Or is it the highest in the tree which would be foo/bar?
I'm just trying to inuit the user's intention. My belief is that for the use
case this feature was designed for (UI extension), the intention would always
be that the sling:resourceType property takes precedence over the node type.
[~gknob] - would you concur?
Perhaps the crux of the problem is that we don't differentiate between the case
when the resource type is defined by the sling:resourceType property and when
it is defined by the node type. I'm certainly of the mind that the latter
should take precedence over the former, but this is obviously a specific
implementation detail of the JCR Resource Provider, so maybe we should be doing
something that checks for the specific implementation class.
In other words, going back to your question of:
bq. What if that resource had "sling:resourceType" set to "nt:unstructured" ?
Then you would end up with the same problem
I do think that this is more meaningful that the resource type being
nt:unstructured because that's what the node type is. In other words, *how* the
resource type is derived is an important factor in determining what the merged
resource type should be. But the "how" information isn't surfaced to the
merger, so we have to use the property.
In practical terms, the change in SLING-4247 creates a significant
backwards-compatibility issues and will require non-trivial changes to most
usages of it (at least those that use our commerical product). If you look at
this project for example:
https://github.com/Adobe-Marketing-Cloud/aem-authoring-extension-header-backtosites,
it would require somewhere between 5 and 10 nodes to have a sling:resourceType
property set on them to achive the pre-SLING-4247 behavior.
> SLING-4247 created odd side-effects
> -----------------------------------
>
> Key: SLING-4340
> URL: https://issues.apache.org/jira/browse/SLING-4340
> Project: Sling
> Issue Type: Bug
> Reporter: Justin Edelson
> Assignee: Justin Edelson
> Fix For: Resource Merger 1.2.4
>
>
> The change made in SLING-4247 created an unfortunate side effect for this
> scenario:
> /apps/a/1/a - nt:unstructured node, no sling:resourceType property
> /apps/a/2/a - sling:resourceType set to foo/bar
> /apps/a/1 has sling:resourceSuperType set to /apps/a/2
> Then
> resourceResolver.getResource("/mnt/override/apps/a/1/a").getResourceType()
> will be nt:unstructured
> This strikes me as wrong. And in fact screws up what is for me the main usage
> of this feature because it shouldn't be necessary to set the
> sling:resourceType all the time.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
