We have built our app to be configurable via OSGi configurations, which is th AEM way.
This works great locally against the cloud SDK.
However, when we deploy to the cloud, the configMgr seems to be blocked. This means we cant edit any of the critical run time variables, such as timeouts, switching features on off etc.
This is a huge problem. It would mean we have to re-write our services to read config from pages of the CMS or similar, which is a significant re-write.
Is there any work around to being able to view and edit our OSGi configs at runtime?
Adobe MUST remove these features from the cloudSDK if they are not available on any cloud env, otherwise we are developing for a completely different system. this also includes the excellent i18n translation system, which is now removed on the cloud, but is still present in the SDK. This also required a significant rewrite, and is a very poor solution now.
that's write. my bad 🙂 sometime it becomes so obvious you forget the immutable part in aem as cloud service!!
As per AEM as Cloud service, all content and code persisted in the immutable repository must be checked into git and deployed through Cloud Manager.
As an example, OSGI configuration should be committed to source control rather than managed at runtime via the AEM web console’s configuration manager.
So you need to make the necessary changes on the developer’s local AEM environment with the AEM web console’s configuration manager and then exporting the results to the AEM project on the local file system. You need to ensure all the OSGi configurations are verified on local environment and commited to source control.
If you want to keep any functionality that needs to be updated during runtime, you can keep those as part of Context aware config which will reside under /conf and can be updated during runtime.
As you said the Cloud and local SDK are not in sync which is really an issue but if we are working on AEM as Cloud environment we need to ensure we follow the concept of mutable and immutable section in AEM and design the application accordingly to overcome these challenges during development.
Please refer the below article which speaks about the different ares of AEM with mutable and immutable concept:
Hope this helps!
Hi, thanks for the reply, could you explain what the /conf is, and how we use it:
All our (non-runtime modifiable) osgi config files are under ui.config, which seems odd, as none of them relate to UI, they all relate to configuring things in core (such as servlets, cors etc).
/conf in AEM holds all the configuration items such as
Context aware config can be created which can be further divided into each site level or locale level and the same can be referenced in any OSGi service, servlet or model classes.
Let's take an example of a single website with 2 different locale such as en_us and en_ca and for each of these locales we want to load different API token across environment, then you can define the same in context aware config and a single peice of code will take the appropriate locale specific value at runtime and these values can be changed at runtime as it will be deployed as part of the content package.
All these settings will be stored under /conf/[project-name]/ with different subfolder names as required by the configuration.
For OSGi configs the file name needs to be same as the PID name and if it's a factory configuration, then we need to add an identifier into it like we do for logger configuration.
Please see the details about the Context Aware Configuration:
In short, if you want to configure something which is different based on environment, it has to be configured in OSGi which cannot be modifed during runtime on AEM as Cloud and needs to be part of the code deployment which will be kept under /apps/project/osgi.... If you want to configure something which is different based on website not based on the environment, it can be configured in Context aware config and can be stored under /conf which can be deployed via code as well as content package and can be modified at runtime using AEM as Cloud.
Thanks for the info. I have read that link twice, but still cant figure it out. I get that there js a /conf in the crxde editor, and I am guessing we would use the crxde editor to edit the settings at run time, is this correct? The next issue is how do we get items into /conf in the right format? we dont have a conf sub project in our source code, we only have things like myapp.ui.config, myapp.ui.content and myapp.core. Second issue, is how do we read this data from a servlet? The link you kindly provided has this linke of code:
Resource contentResource = resourceResolver.getResource("/content/mysite/page1");
But then only has examples reading config properties from htl templates, not from servlets. There some limited info about interfaces, and an example interface with "param1" and "intParam", but there is no obvious way to glue these parameters with the corresponding config object. With osgi, this is done making the file name the same as the PID (with some differences), and then putting the corresponding files in the ui.config under /aem-guides-wknd.ui.config/src/main/content/jcr_root/apps/wknd/osgiconfig/config for example.
Yes, we cannot do any changes related to config manager in higher environment.
We can push it only by code repo.
however you can verify it by developer console and select option as a text.
and search the config name.
You can view the OSGi config from the cloud manager but there is no way to modify it manually in order to prevent inconsistency among instances.
Hey you need to check from developer console https://experienceleague.adobe.com/docs/experience-manager-learn/cloud-service/debugging/debugging-a...
I have a custom implementation as well in case you are interested
sadly, /system/console/status-Configurations isnt available on cloud either. I see the option to download the bundle status in dev console thanks. No option to update it directly sadly.