We're updating the issue view to help you get more done. 

AEMContext not able to adapt to correct implementation class based on the models annotation resourceType property

Description

We implemented an interface with multiple implementations. To determine the "closest" implementation to use when adapting to the interface we configured the resourceType properties on the implementation classes as described here.

https://sling.apache.org/documentation/bundles/models.html#associating-a-model-class-with-a-resource-type-since-1-3-0-

This works on a AEM instance, but when we wrote a test to validate that the correct implementation is used with certain resourceTypes we noticed that the AEMContext is not behaving as we expected.
It seems it doens't take the resourceType property into account when deciding.
Right now when multiple implementations are found, it seems it just takes the first implementation that matches based on the alphabetical order of the class names.

Code example

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 public interface FooterComponent { ... } @Model(adaptables = SlingHttpServletRequest.class, adapters = {FooterComponent.class}, resourceType = "base/components/navigation/footer-component") public class BaseFooterComponentImpl implements FooterComponent { ... } @Model(adaptables = SlingHttpServletRequest.class, adapters = {FooterComponent.class}, resourceType = "custom/components/navigation/footer-component") public class CustomFooterComponentImpl implements FooterComponent { ... }

Test Example

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 @RunWith(MockitoJUnitRunner.class) public class CustomFooterComponentImplTest { @Rule public final AemContext context = new AemContext(); @Before public void setUp() throws Exception { context.load().json("myFooter.json", "/content"); } @Test public void validFooter_validateCorrectImplementationClass() { context.currentPage(); Resource resource = context.resourceResolver().getResource("/content/jcr:content/valid"); context.request().setResource(resource); FooterComponent component = context.request().adaptTo(FooterComponent.class); //expected value based on json assertTrue(component instanceof CustomFooterComponentImpl); } }

Test JSON

1 2 3 4 5 6 7 8 9 { "jcr:primaryType": "cq:Page", "jcr:content": { "jcr:primaryType": "cq:PageContent", "valid": { "sling:resourceType": "custom/components/navigation/footer-component" } } }

We assume that the reason for this behaviour is because the aem-mock still uses an old sling.api version 2.11.0 whereas AEM already uses the newer 2.18.4 version that includes this functionality.
Functionality is available version 2.13+

WCM.io mvn dependency:tree

1 2 3 [INFO] +- io.wcm:io.wcm.testing.aem-mock.junit4:jar:2.6.0:test [INFO] | +- io.wcm:io.wcm.testing.aem-mock.core:jar:2.6.0:test [INFO] | | +- org.apache.sling:org.apache.sling.api:jar:2.11.0:test

AEM 6.4 Sling Api bundle

1 2 3 4 5 6 <dependency> <artifactId>org.apache.sling.api</artifactId> <version>2.18.4</version> <groupId>org.apache.sling</groupId> <scope>provided</scope> </dependency>

Environment

None

Status

Assignee

Unassigned

Reporter

Ben Oeyen

Labels

Components

Priority

Major