Using sling:OsgiConfig nodes and the Felix UI | Community
Skip to main content
Level 3
October 16, 2015
Solved

Using sling:OsgiConfig nodes and the Felix UI

  • October 16, 2015
  • 2 replies
  • 831 views

I'm experimenting with configuration for an OSGi bundle, and getting some results I don't understand.

In CQ 5.4 I created a sling:OsgiConfig node at /apps/client/project/config/package.className with a property of "currentEnvironment". If I view this in the Felix UI, I see my value correctly. But if I edit it in the Felix UI, I don't know where the change is persisted to. The config node still has the same value. I tried stopping and starting the service, and my changes continue to be in effect, but I can't find where it's stored, which leaves me uncertain how it's persisted, or what might cause my changes to be lost. Where is it?

In AEM 5.6.1, I did a similar thing, but when I edit the value in Felix UI, the sling:OsgiConfig node has been deleted and replaced by a nt:file node, with the data stored in text. Is this expected behavior, and is there a way to keep the sling:OsgiConfig node?

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 JustinEd3

Hi Joel,

Both of these are the expected behavior. The OSGi ConfigAdmin service always persists configuration. In this particular implementation (Felix ConfigAdmin), this persistence is done in crx-quickstart/launchpad/config.

In CQ 5.5, there was a feature added which *in addition* writes back configuration nodes into the repository. Unfortunately, the data types in ConfigAdmin cannot be fully represented in JCR properties, so JCR writeback of ConfigAdmin configurations has to use those configuration files. If you follow some of the discussion in https://issues.apache.org/jira/browse/SLING-2477 you'll see more of the backstory (and a potential road forward). If that issue is important to you, I'd suggest filing a DayCare issue in support of it so that Adobe understands the relative priority of this issue.

Regards,

Justin

2 replies

JustinEd3Adobe EmployeeAccepted solution
Adobe Employee
October 16, 2015

Hi Joel,

Both of these are the expected behavior. The OSGi ConfigAdmin service always persists configuration. In this particular implementation (Felix ConfigAdmin), this persistence is done in crx-quickstart/launchpad/config.

In CQ 5.5, there was a feature added which *in addition* writes back configuration nodes into the repository. Unfortunately, the data types in ConfigAdmin cannot be fully represented in JCR properties, so JCR writeback of ConfigAdmin configurations has to use those configuration files. If you follow some of the discussion in https://issues.apache.org/jira/browse/SLING-2477 you'll see more of the backstory (and a potential road forward). If that issue is important to you, I'd suggest filing a DayCare issue in support of it so that Adobe understands the relative priority of this issue.

Regards,

Justin

Level 3
October 16, 2015

Thanks, very helpful.