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

The registration issue in the configuration framework #493

Open
saiedt opened this issue Jun 11, 2018 · 0 comments
Open

The registration issue in the configuration framework #493

saiedt opened this issue Jun 11, 2018 · 0 comments
Assignees

Comments

@saiedt
Copy link
Contributor

saiedt commented Jun 11, 2018

I have the following class in my code:

public class CGwDataConfiguration implements ConfigurableModule { ... }

In another class, I had the following method that could be used to initialize the above class:

public final void init(ConfigurationManager confMgr) {
	if (confMgr != null) {
		CGwDataConfiguration dataConf = new CGwDataConfiguration(this);
		confMgr.register(CGwDataConfiguration.configurations, dataConf);
	}
}

But then I realized that after my budle is run once and the above registration is done once, any further start of the bundle has two unpleasant effects:

  1. In the file \etc\mw.managers.configuration.osgi\configurationDB.ttl you will find as many occurrences of the type definitions for CGwDataConfiguration.configurations as you have run your bundle (with each run, the type restrictions of the configurations are added to the set of previously stored type restrictions, which is absolutely counter productive.
  2. All the previously stored values will be lost and the method CGwDataConfiguration#configurationChanged() is not called.

As a workaround, I tried to find out in my code if my configurations have already been registered and call the register method only if no registration was done before; so, I changed the init() method the following way:

public final void init(ConfigurationManager confMgr, ConfigurationEditor confEditor) {
	if (confMgr != null) {
		CGwDataConfiguration dataConf = new CGwDataConfiguration(this);

		boolean registerModule = true;
		if (confEditor != null) {
			List<EntityPattern> patterns = new ArrayList<EntityPattern>();
			patterns.add(new ApplicationPattern(CGW_CONF_APP_ID));
			patterns.add(new ApplicationPartPattern(CGW_CONF_APP_PART_DATA_ID));
			List<ConfigurableEntityEditor> editors = confEditor.getMatchingConfigurationEditors(patterns, Locale.getDefault());
			if (editors != null)
				for (ConfigurableEntityEditor editor : editors) {
					if (editor instanceof ConfigurationParameterEditor
					&&  dataConf.configurationChanged(editor.getScope(), ((ConfigurationParameterEditor) editor).getConfiguredValue()))
						registerModule = false;
				}
		}

		if (registerModule)
			confMgr.register(CGwDataConfiguration.configurations, dataConf);
	}
}

This prevents the redefinition of the configurations and reads the current values, but de facto there will be no registration for getting notified if the values change over time during the module is running .

I think that this is a bug, and my suggestion for fixing it is to change the interface definition for the register() method by adding a third parameter boolean replaceConfigurations. The implementation probably does not change as long as there are no configurations with the same scope and id, but if such configurations do exist, it must handle the existing configurations dependeing on the value of replaceConfigurations:

  1. If replaceConfigurations == false. then the existing type restrictions and values should not be touched. Only, the configurable module must be notified with the existing values and registered for the future changes of the values.
  2. If replaceConfigurations == true. then first all existing type restrictions and values must be removed and then the same logic as it is now can be applied.

If this change is done, I could get back to my old implementation of my init() method, otherwise I don't know what would be the value of implementing the interface ConfigurableModule.

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

2 participants