Expand my Community achievements bar.

Append Path to SlingServletResolver OSGi Config

Avatar

Level 4

We use a multi-tenant architecture, where each tenant has its own path that needs to be added to the org.apache.sling.servlets.resolver.SlingServletResolver. However, it appears that the SlingServletResolver config lacks a factory setting. Consequently, whenever we add a config JSON at the project level, it tends to overwrite the existing one and retains only the last added configuration.

org.apache.sling.servlets.resolver.SlingServletResolver~tenant1.cfg.json
org.apache.sling.servlets.resolver.SlingServletResolver~tenant2.cfg.json

We suspect our approach might be incorrect because the SlingServletResolver lacks support for factory config. We're exploring a solution to append the new path to the config programmatically. This way, each tenant can have their own config that adds new paths directly to the org.apache.sling.servlets.resolver.SlingServletResolver.cfg.json without overwriting the existing one.

Note: Each tenant is a separate project and not a submodule of the one parent project.

 

 

 

5 Replies

Avatar

Community Advisor

Hi,

 

Typically, what you can do is set this configuration in a "commons" project. This way, it's visible to all other projects and manages configurations that affect the AEM instance's behavior rather than project-related behavior. This can help you organize and avoid errors from overwriting configurations.

 

Hope this helps.



Esteban Bustamante

Avatar

Community Advisor

I'd go for context aware configuration + Granite UI properties.

To manage multi-tenant configurations in AEM without overwriting org.apache.sling.servlets.resolver.SlingServletResolver settings, leverage Context-Aware Configuration (CAC) and Granite UI:

  1. Context-Aware Configuration (CAC): Define tenant-specific settings within the AEM content tree. Use these settings to dynamically adjust servlet behavior or resource resolution, bypassing the need for multiple SlingServletResolver configurations.

  2. Granite UI for Context Management: Create custom component-level propertied from Granite UI, allowing the component to manage their specific configurations within AEM’s authoring environment. This approach replaces direct manipulation of OSGi config files with a more user-friendly method, and the servlet would be able to get the configs.

This strategy offers flexibility, scalability, and a tenant-specific management approach, avoiding the pitfalls of global OSGi configuration conflicts.

Avatar

Employee Advisor

What configuration parameter do you want to add per tenant?

Avatar

Level 4

Hi @Jörg_Hoh

We are trying to add the tenant-specific Execution Paths. For example, /tenant1/, /tenant2/, etc.

As mentioned, since each tenant is a different application and this OSGi config doesn't support factory configuration, we have to maintain the same configuration in multiple projects. If we take this approach, if one tenant config changes, the all other tenants app codebase needs to be updated.

That's why we are looking for an approach where each tenant can have org.apache.sling.servlets.resolver.SlingServletResolver (either JSON or XML) into their codebase, but it should only add a new path to the Execution Paths list and not change or overwrite anything that already exists. That way, tenant one can add /tenant1/, and tenant two can /tenant2/ path.

webdev91_0-1713198620241.png