Java – AEM Sling resource parser mapping method

I’ve been looking on the Internet for more information on configuring Sling Resource Resolver mappings for some time. Based on what I’ve found online and my experience, there are currently two ways to do this in AEM.

1. Via org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl
   OSGi property resource.resolver.mapping
2. Resources specified through the org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl OSGI property resource.resolver.map.location

Mappings for Resource Sling documentation and about on Resolution Resource Mapping Both of the AEM documents seem to recommend using the property resource.resolver.map.location (2) as the recommended method because it is the only way to interpret the document.

I would be happy to clarify this and understand the topic better. I think most online resources on this topic lack depth to explain the differences between the two approaches and the benefits of using one method versus the other. More detailed insights, explanations, and practical illustrations on this topic are very welcome.

Thanks

I can’t give an answer either. However, if you look at the code in MapEntries#doUpdateConfiguration (line 428), you will find that the following entries are eventually merged into the same internal lookup map. So technically there is no difference.

• resource.resolver.virtual
• resource.resolver.mapping
• resource.resolver.map.location

The code see:
https://github.com/apache/sling-org-apache-sling-resourceresolver/blob/master/src/main/java/org/apache/sling/resourceresolver/impl/mapping/MapEntries.java

I understand

As far as I know, at least from day 5, the recommended approach is to use resource.resolver.map.location. This is the most flexible way. Others may still exist for historical reasons.

Large multi-brand/multi-team projects

Another good reason for /etc/map is that large projects with multiple teams and brands must avoid global OSGi configurations (e.g. Unilever). Therefore, many other OSGi configurations also have another way to configure them:

By the configuration factory (Sling Service User Mapper
• /Sling Service User Mapper amendment).
• Through per-service configuration (sling.auth.requirements in the Sling authentication service).
• Or through the global content structure (your /etc/maps example).

In this case, there is always a preference for variants, which allow multiple teams to provide their configuration parts independently. In your case, the team can provide different subtrees under /etc/map

PS: I’m not even sure if the regex works in the OSGi configuration. This also applies to /etc/maps.