Expand my Community achievements bar.

SOLVED

Using sling:OsgiConfig nodes and the Felix UI

Avatar

Level 4

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?

1 Accepted Solution

Avatar

Correct answer by
Employee

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

View solution in original post

2 Replies

Avatar

Correct answer by
Employee

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