Tags
Share
The Effect of Losing Run-Time Flexibility
In AEM as a Cloud Service, the effect is felt immediately: some of the long-standing workflows you once relied on simply aren’t available anymore. A few examples include being unable to install an application package without a new deployment via Cloud Manager, to introduce a very specific runmode, to use a custom logging event filter to redirect or copy log messages, or to run a repository-wide search backed by a standard full-text index.
Most of these changes are manageable, and they often encourage better coding practices. But some pose a challenge because there are simply no equivalent replacements. A clear example is OSGi configurations. The Exadel development team uses them widely to support on-the-fly modifications of custom AEM code, and to adapt service behavior across different AEM instances.
Flexibility Still Matters
Why teams still need runtime control
These use cases show why teams need OSGi configs they can modify at any time:
- deploying an experimental feature with a fallback “disable” switch;
- launching alternative implementations of a feature for A/B testing;
- activating a feature site-wide on a specific date between releases;
- temporarily enabling very detailed logging for a package or namespace to troubleshoot an issue;
- switching between endpoints for a third-party integration when the primary endpoint has problems.
This list is by no means exhaustive, but it highlights some of the most common scenarios teams face in real projects.
The hard limits of AEMaaCS alternatives
In AEM Cloud, OSGi configurations were moved to the immutable segment of the content repository. The Felix console for manually editing them was removed entirely. You can no longer change configurations between releases. Some online opinions suggest that this is generally for the best and that alternative options are available. In our experience, however, none of these options is a fully suitable replacement. Here’s why:
- Environment variables are limited in both number and value size. Changing one triggers an environment rebuild.
- Sling Context-Aware Configuration can work in some scenarios, but it is resource-oriented and better suited for rendering content in different “folders” than for controlling system-wide services or servlets. It is also trickier to manage.
- Sling feature flags cover only simple enable/disable cases. They do not modify out-of-the-box configurations like logging levels.
- Storing settings in a modifiable resource (under /conf or in page properties) requires custom logic to edit the settings in the UI, retrieve them in the corresponding service and, most importantly, notify that service when a setting changes.
Why classic OSGi is hard to match
Frankly, none of these options matches the classic OSGi approach: create a service; define what type of settings are needed (with OSGi annotations); provide meaningful defaults in the same place and let Apache Felix render a basic UI for editing those settings; then rely on Felix to restart (or reconfigure) services whenever a setting changes—whether through the UI or via a content package.
Restoring Control with the Exadel Configurator
We had sound technical reasons for wanting to preserve the original OSGi-style approach. But since this was no longer possible in AEM Cloud, we built a solution that restored this capability. It is now part of Exadel’s EToolbox Authoring Kit, alongside other tools that simplify AEM development and content authoring.
We call this solution Configurator and you can find out more about it in the EToolbox Authoring Kit manuals: https://authoring-kit.com/content/dev-tools/configurator. The idea is to restore the Felix console experience, but in modern AEM Granite UI and with proper security restrictions.
What Configurator lets you do
Configurator provides a list of all OSGi configurations registered in the system, accessible only to users with elevated privileges. It also provides a dedicated “personal page” for each configuration. You can grant access to a specific configuration page for a user or group, including non-privileged users, provided they are authorized to change that configuration. They do not gain access to anything else.
Runtime configuration control restored
Configurations can once again be modified at runtime because they are stored in the mutable section of the content repository, while still being backed by the native Apache Felix configuration manager. Both out-of-the-box and custom configurations are supported. The solution has been proven to work in an AEM Cloud cluster: changes made on a configuration page propagate across all Author instances and can be delivered to Publisher instances using native Sling Content Distribution. These changes also survive automatic instance rotation and project redeployments.
Pick the Right Partner for Your AEM Cloud Migration.
What This Means for AEM Teams
With the EToolbox Configurator in AEMaaCS, perfectly serviceable OSGi configurations are no longer forced into early retirement. Development teams can continue using the familiar @Component / @Designate / @ObjectClassDefinition pattern. As a bonus, developers gain a straightforward, access-controlled way to create configuration pages for custom functionality—something the Content Team can confidently use.
We’ll continue sharing practical insights as we explore new ways to help AEM teams stay flexible and productive in the Cloud. More to come in future articles.
Discover the capabilities of EToolbox Authoring Kit at https://authoring-kit.com.
