Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Configuration persistence never cleaned #54

Closed
fipro78 opened this issue May 11, 2022 · 6 comments
Closed

Configuration persistence never cleaned #54

fipro78 opened this issue May 11, 2022 · 6 comments

Comments

@fipro78
Copy link
Contributor

fipro78 commented May 11, 2022

Hi,

while investigating on the behavior of different OSGi runtimes I noticed that the persistence is never cleared when using Atomos.

Attached are two simple setups that use Atomos. The application is basically a Gogo Shell with some commands that use SCR, ConfigAdmin and EventAdmin to verify if things are working.

For Felix the system property -Dorg.osgi.framework.storage.clean=onFirstInit should clean the persistence on start.
For Equinox I assumed -clean should do the same.

In both cases the persistence is never cleared. You can check this by starting the application and then call fipro:configure <some_value>. Then call fipro:welcome which actually reads the configuration value and prints it to the console. Then stop the application and start it again. With the mentioned clean parameters the welcome command should print null, but it always prints the previously configure value. So the configuration persistence area is never cleared.

folder_atomos_equinox.zip
folder_atomos_felix.zip
.

@tjwatson
Copy link
Member

For Felix the system property -Dorg.osgi.framework.storage.clean=onFirstInit should clean the persistence on start.
For Equinox I assumed -clean should do the same.

org.osgi.framework.storage.clean=onFirstInit is a standard OSGi property that should work across both Felix and Equinox.

@karlpauls
Copy link
Contributor

At least for Felix, I don't think org.osgi.framework.storage.clean works as a system property. It will work if used as a framework property.

In other words, for Felix, I think you need to pass it as an argument to the Atomos launcher - i.e., something like:

java -cp "bundles/*" org.apache.felix.atomos.Atomos org.osgi.framework.storage.clean=onFirstInit

@tjwatson
Copy link
Member

tjwatson commented May 11, 2022

The issue is Atomos main does not understand -clean argument for the equinox case. For the org.osgi.framework.storage.clean property, that is a framework launch option. Frameworks are not obligated to read that from the System properties. Only from the Map of properties passed to org.osgi.framework.launch.FrameworkFactory.newFramework(Map<String, String>) is able to set that. As Karl says you can pass that as (non -D) arguments to Atomos main. See org.apache.felix.atomos.Atomos.main(String...)

@fipro78
Copy link
Contributor Author

fipro78 commented May 11, 2022

Everyday I learn a new detail. Thanks for the explanation. I will verify tomorrow and give a feedback here.

Btw, the system property works with the Felix launcher. Probably that is why I thought it should also work with atomos this way.

@karlpauls
Copy link
Contributor

@fipro78, right - that is done by the Felix main [0]. The framework is only using the framework properties.

[0] https://github.com/apache/felix-dev/blob/2bacc598b1cd00e84c69c54a3c77a03288204c6c/main/src/main/java/org/apache/felix/main/Main.java#L568

@fipro78
Copy link
Contributor Author

fipro78 commented May 12, 2022

Hi,

just in case someone is coming across this issue in the future, I can confirm that:

  • With Atomos org.osgi.framework.storage.clean=onFirstInit needs to be passed as argument to the Atomos launcher as described by @karlpauls
  • Using the Equinox Framework directly (start via -jar org.eclipse.osgi) it can be passed as system property or you can use -clean
  • Using the Felix Framework with the Felix Launcher (org.apache.felix.main) org.osgi.framework.storage.clean=onFirstInit can be set as system property

Thanks @tjwatson and @karlpauls for the explanation.

@fipro78 fipro78 closed this as completed May 12, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants