[
https://issues.apache.org/jira/browse/SLING-10212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kyle Giovannetti updated SLING-10212:
-------------------------------------
Description:
I have found that the behaviour of the Model Adapter is not as I would expect
when no model implementation matches the adaptable objects resources resource
type.
My analysis is based on stepping through the adapter to debug an issue.
I would appreciate if someone with a more intimate understanding of Sling
Models could verify this behaviour.
The issue arises when there are multiple implementations, and one of those
implementations does not declare a `resourceType`.
For example:
{code:java}
public interface SomeModel {
// ...
}{code}
{code:java}
@Model(adaptables = SlingHttpServletRequest.class, adapters = SomeModel.class,
resourceType = "project/A")
public class A_Impl implements SomeModel {
// ...
}{code}
{code:java}
@Model(adaptables = SlingHttpServletRequest.class, adapters = SomeModel.class,
resourceType = "project/B")
public class B_Impl implements SomeModel {
// ...
}
{code}
{code:java}
@Model(adaptables = SlingHttpServletRequest.class, adapters = SomeModel.class)
public class C_Impl implements SomeModel {
// ...
}
{code}
Now, let us assume that we are adapting a request for which the resource type
is "X".
Neither `project/A` or `project/B` have a parent resource type of "X".
The adapter will first run through the `ResourceTypeBasedResourcePicker`, which
will not produce any model implementation suitable for the resource type "X".
The adapter will then fall back on the "FirstImplementationPicker", and now,
if the implementations are in the order specified above, the implementation
`A_Impl` will be chosen - despite the fact that the `resourceType` does not
match.
I would expect that `C_Impl` would be chosen instead.
Although `C_Impl` does not match a `resourceType`, it at least does not have
the wrong `resourceType`.
A possible solution to implement this is to add another ImplementationPicker
(e.g. "DefaultImplementationPicker") that is positioned between the
`ResourceTypeBasedResourcePicker` and the `FirstImplementationPicker`. This new
implementation picker would only return implementations that do not define any
`resourceType` at all.
Thus the order of precedence for model implementation selection would be:
# The model implementation with the closest matching `resourceType`
# A model implementation with no `resourceType`
# The first model implementation
was:
I have found that the behaviour of the Model Adapter is not as I would expect
when no model implementation matches the adaptable objects resources resource
type.
My analysis is based on stepping through the adapter to debug an issue.
I would appreciate if someone with a more intimate understanding of Sling
Models could verify this behaviour.
The issue arises when there are multiple implementations, and one of those
implementations does not declare a `resourceType`.
For example:
{code:java}
public interface SomeModel {
// ...
}{code}
{code:java}
@Model(adaptables = SlingHttpServletRequest.class, adapters = SomeModel.class,
resourceType = "project/A")
public class A_Impl implements SomeModel {
// ...
}{code}
{code:java}
@Model(adaptables = SlingHttpServletRequest.class, adapters = SomeModel.class,
resourceType = "project/B")
public class B_Impl implements SomeModel {
// ...
}
{code}
{code:java}
@Model(adaptables = SlingHttpServletRequest.class, adapters = SomeModel.class)
public class C_Impl implements SomeModel {
// ...
}
{code}
Now, let us assume that we are adapting a request for which the resource type
is "X".
Neither `project/A` or `project/B` have a parent resource type of "X".
The adapter will first run through the `ResourceTypeBasedResourcePicker`, which
will not produce any model implementation suitable for the resource type "X".
The adapter will then fall back on the "FirstImplementationPicker", and now, if
the implementations are in the order specified above, the implementation
`A_Impl` will be chosen - despite the fact that the `resourceType` does not
match.
I would expect that `C_Impl` would be chosen instead.
Although `C_Impl` does not match a `resourceType`, it at least does not have
the wrong `resourceType`.
A possible solution to implement this is to add another ImplementationPicker
(e.g. "DefaultImplementationPicker") that is positioned between the
`ResourceTypeBasedResourcePicker` and the `FirstImplementationPicker`. This new
implementation picker would only return implementations that do not define any
`resourceType` at all.
Thus the order of precedence for model implementation selection would be:
# The model implementation with the closest matching `resourceType`
# A model implementation with no `resourceType`
# The first model implementation
> Prioritize model with no `resourceType` when no resource type matches
> ---------------------------------------------------------------------
>
> Key: SLING-10212
> URL: https://issues.apache.org/jira/browse/SLING-10212
> Project: Sling
> Issue Type: Improvement
> Components: Sling Models
> Reporter: Kyle Giovannetti
> Priority: Major
>
> I have found that the behaviour of the Model Adapter is not as I would expect
> when no model implementation matches the adaptable objects resources resource
> type.
>
> My analysis is based on stepping through the adapter to debug an issue.
> I would appreciate if someone with a more intimate understanding of Sling
> Models could verify this behaviour.
>
> The issue arises when there are multiple implementations, and one of those
> implementations does not declare a `resourceType`.
> For example:
>
> {code:java}
> public interface SomeModel {
> // ...
> }{code}
>
> {code:java}
> @Model(adaptables = SlingHttpServletRequest.class, adapters =
> SomeModel.class, resourceType = "project/A")
> public class A_Impl implements SomeModel {
> // ...
> }{code}
>
> {code:java}
> @Model(adaptables = SlingHttpServletRequest.class, adapters =
> SomeModel.class, resourceType = "project/B")
> public class B_Impl implements SomeModel {
> // ...
> }
> {code}
>
> {code:java}
> @Model(adaptables = SlingHttpServletRequest.class, adapters =
> SomeModel.class)
> public class C_Impl implements SomeModel {
> // ...
> }
> {code}
>
> Now, let us assume that we are adapting a request for which the resource type
> is "X".
> Neither `project/A` or `project/B` have a parent resource type of "X".
> The adapter will first run through the `ResourceTypeBasedResourcePicker`,
> which will not produce any model implementation suitable for the resource
> type "X".
> The adapter will then fall back on the "FirstImplementationPicker", and now,
> if the implementations are in the order specified above, the implementation
> `A_Impl` will be chosen - despite the fact that the `resourceType` does not
> match.
> I would expect that `C_Impl` would be chosen instead.
> Although `C_Impl` does not match a `resourceType`, it at least does not have
> the wrong `resourceType`.
> A possible solution to implement this is to add another ImplementationPicker
> (e.g. "DefaultImplementationPicker") that is positioned between the
> `ResourceTypeBasedResourcePicker` and the `FirstImplementationPicker`. This
> new implementation picker would only return implementations that do not
> define any `resourceType` at all.
> Thus the order of precedence for model implementation selection would be:
> # The model implementation with the closest matching `resourceType`
> # A model implementation with no `resourceType`
> # The first model implementation
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
