Common Config folder not activating osgi component | Community
Skip to main content
Adilmo
Adilmo
September 3, 2020
Solved

Common Config folder not activating osgi component

  • September 3, 2020
  • 1 reply
  • 1343 views

Hi All, 

 

We have following structure 

 

/apps/*/config  -  (sling:folder)

/apps/*/config.author   -  (nt:folder)  

/apps/*/config.author.dev   -  (nt:folder)  

 

We are running aem with author runmodes [dev, author]. 

 

Now when we deploy these folders only configs from config.author.dev activate the osgi component. Even if we manually change configs in /apps/*/config folder it does not activate my component with new config. 

 

However, if we change configs under config.author.dev it does reactivate my component with the configs under the config.author.dev folder. 

 

Documentation says config is applicable to all run modes. So just wondering if this behavior is correct. 

 

Further, do we need have all the folders as sling:folder rather than nt:folder. What is the purpose of declaring a folder as sling:folder ? 

 

 

 

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by Andrei_Dantsou

Hello @adilmo,

The behavior you've described is expected, since if there are several config folders with multiple run modes combined, the most specific one is applied. In your case config.author.dev has a priority over just config or config.author. More details about config resolution order can be found here (please see the "Resolution of multiple Run Modes" section).

The documentation suggests using sling:folder for managing OSGI configs. Differences between sling:folder and nt:folder (please see the link for reference):

nt:folder - This node type represents a plain file system folder (it can have nt:folder and nt:file children and only a few restricted meta data properties) // so quite restricted in terms of properties and nodes.

sling:folder - This node type is basically nt:folder + nt:unstructured in one, i.e. it can be used inside other nt:folders. // should be used more often.


Regards

1 reply

Andrei_Dantsou
Andrei_DantsouAccepted solution
September 3, 2020

Hello @adilmo,

The behavior you've described is expected, since if there are several config folders with multiple run modes combined, the most specific one is applied. In your case config.author.dev has a priority over just config or config.author. More details about config resolution order can be found here (please see the "Resolution of multiple Run Modes" section).

The documentation suggests using sling:folder for managing OSGI configs. Differences between sling:folder and nt:folder (please see the link for reference):

nt:folder - This node type represents a plain file system folder (it can have nt:folder and nt:file children and only a few restricted meta data properties) // so quite restricted in terms of properties and nodes.

sling:folder - This node type is basically nt:folder + nt:unstructured in one, i.e. it can be used inside other nt:folders. // should be used more often.


Regards

    Andrei_Dantsou
    Andrei_Dantsou
    September 3, 2020

    @adilmo,

    your understanding is correct - if a config is not present neither in config.author.dev nor in config.author, it should be take from the config folder. If your goal is to apply the configuration from the config folder via deployment of a maven project, then please make sure that the desired config is not present in more specific folders (config.author.dev, config.author) and you might also need to remove the config from /apps/system/config and crx-quickstart/launchpad/config prior to the deployment. The mentioned locations might store the configuration applied manually and prevent the latest one deployed via your project from being applied.

    Regards

    Terms & ConditionsAccessibility statement

    Loading footer...