简体   繁体   English

AEM Sling 资源解析器映射方法

[英]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.一段时间以来,我一直在 Internet 上寻找有关配置Sling Resource Resolver映射的更多信息。 From what I found online and my experience there are currently two methods accomplishing this in AEM.根据我在网上的发现和我的经验,目前有两种方法可以在 AEM 中实现这一点。

  1. Through the org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl OSGi property resource.resolver.mapping通过org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl OSGi 属性resource.resolver.mapping
  2. Through the resources specified by the org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl OSGI property resource.resolver.map.location通过org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl OSGI 属性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. 关于资源解析映射的 Sling 文档和关于资源映射的 AEM 文档似乎都建议使用利用属性resource.resolver.map.location的方法 (2) 是推荐的方法,因为它是唯一的方法由文档解释。

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谢谢

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.但是,如果您查看MapEntries#doUpdateConfiguration (第 428 行)中的代码,您会发现以下条目最终合并到同一个内部查找映射中。 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查看代码: 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 .根据我的理解,至少从第 5 天开始,推荐的方法是使用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). /etc/map另一个很好的理由是,具有多个团队和品牌的大型项目必须避免全局 OSGi 配置(考虑像联合利华这样的东西)。 Therefore many other OSGi configs have also an alternative way to configure it:因此,许多其他 OSGi 配置也有另一种配置方式:

  • by a config-factory (Sling Service User Mapper / Sling Service User Mapper Amendment)通过配置工厂(Sling Service User Mapper / Sling Service User Mapper Amendment)
  • by a per-service config (sling.auth.requirements in the Sling Authentication Service)通过每个服务配置(Sling 身份验证服务中的 sling.auth.requirements)
  • or by a global content structure (your example with /etc/maps)或通过全局内容结构(您的示例与 /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在您的情况下,团队可以在/etc/map下提供不同的子树


PS: I'm even not sure, if regex are working in the OSGi configs. PS:我什至不确定,如果正则表达式在 OSGi 配置中工作。 This speaks for /etc/maps too.这也适用于/etc/maps

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM