CODEWITHSUNDEEP
javaconfigurationosgiaemsling
nabello
nabello

Reputation: 826

AEM Sling Resource Resolver Mapping Methods

I have been poking around the Internet for some time looking for more information on configuring Sling Resource Resolver mappings. From what I found online and my experience there are currently two methods accomplishing this in AEM.

  1. Through the org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl OSGi property resource.resolver.mapping
  2. Through the resources specified by the org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl OSGI property resource.resolver.map.location

The Sling documentation on Mappings for Resource Resolution and the AEM documentation on Resource Mapping both seem to suggest that using the method (2) that makes use of the property resource.resolver.map.location is the recommended way given that it is the only method explained by the documentations.

I'd love to clear this up and gain a better understanding on this topic. I think most of the online resources on this subject lack of depth in explaining the differences in both methods and the benefits in using one versus the other. More detailed insight, explanations and practical illustrations on this topic are highly welcomed.

Thanks

Upvotes: 3

Views: 3112

Answers (1)

Alexander Berndt
Alexander Berndt

Reputation: 1728

I also can't give an answer. But if you look into the code at MapEntries#doUpdateConfiguration (line 428), then you can see that the following entries are finally merged into the same internal lookup-map. So technically there is no difference.

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

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

My Understanding

In my understanding at least since Day CQ 5 the recommended way is to use resource.resolver.map.location. It is the most flexible way. The others are probably still there for historic reasons.

Large Multi-Brand / Multi-Teams Projects

Another good reason for /etc/map is, that large projects with multiple teams and brands have to avoid global OSGi configs (have something like Unilever in mind). Therefore many other OSGi configs have also an alternative way to configure it:

  • by a config-factory (Sling Service User Mapper / Sling Service User Mapper Amendment)
  • by a per-service config (sling.auth.requirements in the Sling Authentication Service)
  • or by a global content structure (your example with /etc/maps)

In such cases always prefer the variant, which allows multiple teams to independently provide their part of the config. In your case the teams could provide different sub-trees under /etc/map

PS: I'm even not sure, if regex are working in the OSGi configs. This speaks for /etc/maps too.

Upvotes: 3

Related Questions