DIIRT preferences cannot be overridden

[nickbattam]

We have identified some behaviour in the DIIRT preferences that does not mirror the way other CS-Studio plugin preferences are handled. This difference in behaviour means that we are unable to set custom DIIRT preferences for groups of users that require a custom configuration to be set.

For "normal" plugins, preferences are read from the plugin_customization.ini file that override defaults set in the plugin. When a preference value is changed in the UI the new value is saved to the workspace .metadata/.plugins/org.eclipse.core.runtime/.settings/ folder.

If the -pluginCustomization option is used at the command line to pass a modified set of preferences, the value in the passed configuration file overrides the value from the plugin_customization.ini file and default, but not a value that has been saved into the workspace settings folder.

For the DIIRT preferences, all preferences from the plugin_customization.ini file (and the unset defaults) are as saved directly into the workspace folder so it is not possible to override them later with the command line flag.

Is this behaviour intentional or an unintended consequence of way the PreferenceStore is used to support the complex preferences management needed to build the DIIRT config files?

[claudio-rosati]

It is a consequence of the way the PreferenceStore is used to support the complex preferences management needed to build the DIIRT config files.

If a DIIRT configuration folder is provided, the content of the xml files in this folder (ca and datasource) becomes the current default, that can be overridden by the user through the Preferences dialog. For this reasons all preferences are as saved directly into the workspace folder.

There was contrasting needs, and this was the solution solving them all. If you need something different we can think about it. Meybe a new CLI property (-DdiirtOverride=true or something telling us that the -pluginCustomization was used) that if set will force clearing the saved values. Let me know your opinion.

[kasemir]

For what it's worth, I really like the original Eclipse preference approach, because it allows for defaults at the plugin (each_plugin/preferences.ini), overrides when assembling the product (product_plugin/plugin_customization.ini), overrides from the command line (-pluginCustomization my_settings.ini) plus each user can then also adjust and that's stored in the workspace.

Bending over backwards to accomodate the diirt xml files has resulted in several renames of the preference names and still brings up issues.

Would it make sense to step back and make this swtichable?

• diirt gets a preference interface. By default that's not configured. If you try to create a PV you get an NPE("No preferences")
• Applications that include diirt need to set the preference implementation.
• Diirt does include one that reads XML files
• CSS includes one that reads Eclipse preferences

--> No need for CSS to create the XML files

[claudio-rosati]

I like it. @shroffk what do you think?

[kasemir]

One motivation for the diirt XML files was that certain data sources need very complex configuration that doesn't map to eclipse preferences.
Fine, those data sources can have a preference (from a diirt xml resp. from an Eclipse preference) for the path to the data source XML.

Still, 99% of our PVs are Channel Access, starting to add PVAccess, where the configuration was plain enough to map into Eclipse preferences with UI. For those there is a need to adjust the EPICS_CA/PVA_ADDR_LIST in a way that was nicely supported by the hierarchical preference approach offered by Eclipse.

[shroffk]

Initially we had thought of having the configuration provider be an interface with the implementation provided by java SPI....something osgi does not like.

Could this be finalized at the F2F in June?

[nickbattam]

@shroffk That sounds like a good idea.

I have created a crude workaround for problem in our particular use-case(*) that we can use until a re-engineered diirt configuration is available

*: deleting org.csstudio.diirt.util.core.preferences.prefs from the workspace before launch .