Expand my Community achievements bar.

SOLVED

AEM 6.2: Deployment of OSGi Settings for different environments does not work correctly

Avatar

Level 2

Hello everyone,

 

I have two different OSGi-Configurations. One shall be used for the productive system, the other configuration for all other environments (like dev and integration system). The plan is to deploy these settings to the right environment through configration files. The needed folder structure was already existent in the repository I am working with (like "config", "config.prod", "config.prod.publish", "config.dev" and so on.....)

 

I have placed the .conf files in the right folder structure: "config.prod" for the productive data and in "config" for all the other environments. 

 

The runmodes for the author of the productive system are: "author,prod,crx3,crx3tar".

 

As you can read in the documentation the configuration folder that matches the most runmodes will be used to lookup the .conf file. In this case this is clearly "config.prod". But after deployment I find the configuration that was placed into "config" on the productive System (system/ConfigMgr). 

 

The configuration of "config.prod" is not "overloaded" through a more matching config folder either (like for instance "config.prod.author").

 

Does anyone of you have a clue, why this might happen? Or how I can determine what has happended?

 

Greetings, Christoph

1 Accepted Solution

Avatar

Correct answer by
Level 2

Yes that helped. I used the folder "config.author.local" to deploy the config to my local dev system. The file from "config" worked, the file from "config.prod" not.

 

After inspecting the files closely I found out what was wrong. The encoding and properties were ok, but inside the file I did not put the values of the key-value-pairs into "". That broke the file. 

 

Very **bleep** error to be honest. But I simply did not see that although checking the files several times before. 

 

Thank you all for helping!

 

 

View solution in original post

10 Replies

Avatar

Community Advisor

Hi @ChristophSchnaedter 

 

In AEM If multiple configurations for the same PID are available, the configuration with the highest number of matching run modes is applied.

 

As I understand you already the same configuration available in both config.prod as well as in config. So in this case the configuration should be picked from config.prod.

 

If it's not picking from the correct location, that means there is a typo in the PID name that is present in the config.prod which is why it's not finding a match and it's looking for the next available match which is config. Please review the PID names and ensure the names are exactly matching what is expected and it should resolve the issue.

 

Thanks!

Avatar

Community Advisor

Hi Christoph,

 

I second what Asutosh is telling. Adding more to his point and to avoid typos i would suggest you to copy the required working configuration node from config folder and paste this node in config.prod. Then change the properties which should be different in production environment. This way you will be sure that there are no typos in the pid.

 

Thanks

Avatar

Level 2

Thanks for the replies. I checked the configs and both filenames are exactly the same. If I copy one of the configs in the other folder the OS asks me whether I want to replace the existing file as both file names are equal. 

Avatar

Community Advisor

Do you have the jcr:primaryType set to sling:OsgiConfig?

Avatar

Level 2

jcr:primaryType is set to "nt:file" but this is the case with all our config files.

 

But there is a difference when I check the jcr content nodes. In "config.prod" there is a property "jcr:mimeType: application/octet-stream" and in "config" the property is "jcr:mimeType: text/plain" and also a property that says encoding is UTF-8.

 

So maybe the config from "config.prod" is invisible to aem because of wrong encoding?

Avatar

Community Advisor

I would suggest to take a back up of the existing config under config.prod, delete the config from config.prod then copy the required config from config to config.prod. Then change the values to reflect the prod properties.

As this is a prod environment we are talking about you could first test this in your local or lower environments and try on prod later.

Avatar

Correct answer by
Level 2

Yes that helped. I used the folder "config.author.local" to deploy the config to my local dev system. The file from "config" worked, the file from "config.prod" not.

 

After inspecting the files closely I found out what was wrong. The encoding and properties were ok, but inside the file I did not put the values of the key-value-pairs into "". That broke the file. 

 

Very **bleep** error to be honest. But I simply did not see that although checking the files several times before. 

 

Thank you all for helping!

 

 

Avatar

Community Advisor

Hi @ChristophSchnaedter 

 

Can you please check if you do not have the same configuration available under the below path?
/apps/system/config

 

Just to ensure your configuration is picking from config folder rather than config.prod can you update some value in config folder and redeploy the code and validate the same in system/console/configMgr?

 

If the value is updated, then it's picking from config and we can change the order of the file name. If it does not pick then the config is picked from system/config and you need to remove this folder manually.

Thanks!

Hi @Asutosh_Jena_ 

 

There is no config under /apps/system/config.

 

And changing some values in config folder and reploying is not that easy as we have that problem with deployment on productive system. I would have to wait for the next scheduled release.

Avatar

Level 2

I guess it is worth mentioning that we are using an OSGi factory here as we want to have different configs for different countries.

The distinction happens with a country suffix in the filename. (like ....ConfigImpl-us oder ConfigImpl-uk.....). When I check the configs under system /ConfigMgr i can see that this suffix has been transformed into a long alphanumeric code for the PID. But the factory pid is as expected.