You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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:
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.
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.
The text was updated successfully, but these errors were encountered:
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:
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:
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:
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 ofreplaceConfigurations
: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.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.
The text was updated successfully, but these errors were encountered: