Append Path to SlingServletResolver OSGi Config

[webdev91]

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.

[EstebanBustamante]

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.

[BrianKasingli]

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.

[Rajendar_Gangan]

Could you please provide example code?

[Jörg_Hoh]

What configuration parameter do you want to add per tenant?

[webdev91]

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.

[neerav_it]

We are also facing similar issue. @webdev91  Did you find any code solution for this?

[webdev91]

Hi @neerav_it

We already had a common project for managing the dispatcher module for all the tenant projects. So we ended up adding the ui.config module to the common project and now loading all the common OSGi config or the config that doesn't support factory settings from the common project, like SlingServletResolver, Externalizer, etc. I couldn't find any alternative solution, but I would be curious to know if you end up doing something different.

Thank you!