Storage location for ConfigAdmin

[fipro78]

Hi,

I created a small OSGi application based on Equinox. I then created a small JVM using Atomos and jlink. It works quite nice, but it seems the configuration I apply at runtime is not persisted.

I had the same issue with a similar setup using the Felix bundles. I ended up adding

-Dfelix.cm.dir="<CONFIG_PERSISTENCE_FOLDER>"

to the start script JLINK_VM_OPTIONS. For the Felix jlink JVM this works fine and the folder is created with the persisted configuration.

But I am not able to do this for the Equinox ConfigAdmin. Looking at the ConfigurationStore it seems to always use the BundleContext and does not support any other configuration. I then thought to set the configuration area via

-Dosgi.configuration.area="<CONFIG_PERSISTENCE_FOLDER>"

but that doesn't have any effect.

Is there any way to specify the location where the configuration should be persisted? Should it be osgi.configuration.area to specify the whole configuration folder and bundle cache? Or is there another system property I haven't found yet?

[laeubi]

Any chance you have something like -clear in your config or similar options?

[fipro78]

No, I am bundling my executable jar using bndtools and then create the jlink image. No such options.

[laeubi]

Ah I missed that you package it in a special way. Equinox uses the "persistent storage area provided for the bundle by the framework" (see org.eclipse.equinox.internal.cm.ConfigurationStore.ConfigurationStore(ConfigurationAdminFactory, BundleContext)) that is if your Framework does not support such an area (what is optional) it won't persist anything (and it is not configurable).

I always used felix fileinstall in standalone applications as it allows to read and write back configurations and you are not bound to the specific storage mechanism of the underlying CM service.

[laeubi]

By the way I think its won't be hard to add support for something like -Dequinos.cm.dir=... if you take a look at the code, so I think contributions are welcome :-)

[tjwatson]

Are you saying that the framework is not correctly persisting the bundle data area from one launch of Atomos to the next? If you have steps to reproduce that may clear things up.

[fipro78]

@tjwatson That is exactly what I am saying. And I just noticed that it is not only related to Atomos. It also happens for executable jars created via bndtools and the default bnd launcher.

Attached is the example that I use for verification. The project is based on Maven and uses Bndtools for building. You can build via

mvn clean verify

Note that you need Java 17 and a toolchains.xml to make it work without modification. In the .app projects/target you will then find the app.jar files. If you start them, a Gogo Shell opens. Via configure <value> a configuration can be applied. The configured value is the used by using the welcome command. Stopping the application and restarting it will show that the configuration is not persisted.

The same is true if the atomos.jar is used to create a native image via jlink.

Is this maybe related to the bnd launcher? For Felix I can set felix.cm.dir as system property and get it working. But I am not sure what to set for Equinox.

org.fipro.osgi.runtime.evaluation.zip .

[rotty3000]

Have you tried either of these bndrun instructions?

-runkeep: (true|false) – Keep the framework working directory. That is, do not clean at start up -runstorage: <path> – The working directory

[fipro78]

Thanks @rotty3000, that did the trick for the executable jar. Although setting the -runstorage instruction to be a relative path results in a full qualified path that points to the build directory in the executable jar.

If I override the value by starting the application like this:

java -jar -Dlaunch.storage.dir=config app.jar

the config folder gets created and the configuration persisted.

But if I use jlink to create a minimal JVM via:

jlink \
  --add-modules equinox.app \
  --compress=2 \
  --module-path atomos.jar \
  --no-header-files \
  --no-man-pages \
  --launcher start=equinox.app \
  --output jlink_output

and the set JLINK_VM_OPTIONS=-Dlaunch.storage.dir=config in the start script, the config folder gets created, but it isn't loaded on the next startup. I had the config folder open, and could see that on the next startup the configuration data is cleared. Which doesn't happen with the executable jar. Seems -runkeep: true is ignored in the jlink image.

[fipro78]

Sorry, the last information is incorrect. I used the wrong jar for jlink. :(

After I rebuild with the correct atomos.jar that has the launcher.keep=true, everything works as expected.

Thanks for the fast replies. Of course it was missing information about the necessary configuration on my side.