I've seen OSGI configurations use as nt:file or sling:OsgiConfig interchangeably. What the best practice? Why is nt:files used? Are. there any other variations?
Why does core components. follow the nt:file pattern, /apps/core/wcm/config.author/com.day.cq.wcm.foundation.forms.impl.FormParagraphPostProcessor-core-components.config?
Why does we-retail follow the sling:OsgiConfig pattern, /apps/weretail/config/org.apache.sling.commons.log.LogManager.factory.config-we-retail?
Solved! Go to Solution.
There are now a few ways how you can configure OSGI configurations via the repository: Using sling:osgiConfig nodes, using an nt:file with the properties (in a ini-style format), and there is/will be a JSON variant ...
In the end it doesn't matter which one to use; when you are going to edit it in the IDE and store it in GIT, dropping a file is probably the easiest because you don't have the overhead of XML (as you have in the case of using sling:osgiConfig). Storing it as JSON is part of the latest AEM versions, so not yet widespread, thus I wouldn't recommend it today for general use.
regards
Jörg
If you are creating repository based config then use sling:OsgiConfig
If you want to manage configurations using web console then you can use nt:file.
As soon as you update sling:OsgiConfig type config from web console, it converts into nt:file.
There are now a few ways how you can configure OSGI configurations via the repository: Using sling:osgiConfig nodes, using an nt:file with the properties (in a ini-style format), and there is/will be a JSON variant ...
In the end it doesn't matter which one to use; when you are going to edit it in the IDE and store it in GIT, dropping a file is probably the easiest because you don't have the overhead of XML (as you have in the case of using sling:osgiConfig). Storing it as JSON is part of the latest AEM versions, so not yet widespread, thus I wouldn't recommend it today for general use.
regards
Jörg
Sharing the doc[1] where everything is explained in detail.
Views
Likes
Replies