Eclipse Preference store persistance

Question

I have a multiple user/location RCP application that currently utilizes several user configurable options. Some preferences are for specific to the station, some are specific to the user.

The options are from a preference store which saves the *.prefs files to "workspace.metadata.plugins\\org.eclipse.core.runtime.settings".

This would be fine if we were only using a single machine/user. But if a user were to go to another station, then the user would be using whatever preferences were setup for that station.

Is it possible to specify another form for persistence (not files)?

Answer 1

According the the eclipse wiki , the preferences are file-based, and stored:

• for each installation (but this may vary for multi-user installations), in files stored in <eclipse_home>/eclipse/configuration/.settings/ .
  There is typically one file per plugin, with a .prefs extension.
  Note that very few plug-ins use installation-wide preferences.
• for each workspace, in files stored in <workspace>/.metadata/.plugin/org.eclipse.core.runtime/.settings .
  There is typically one file per plugin, with a .prefs extension.
• for each project --for project-level settings -- in files stored in a .settings sub-directory of your project folder

So if the file option is here to stay, you may need to:

• either export/reimport the session settings manually in a user-specific directory (tedious)
• or make some kind of automated mechanism:
  • to export the settings to the user's registry ( HKEY_CURRENT_USER/Software/MyRCP/... ) at the exit of the application, and
  • to import them by reading those registry keys and overriding the .prefs files in the local workspace.metadata.plugins\\org.eclipse.core.runtime.settings directory
• or share those settings through some kind of user-specific link (a wrapper around the startup of the RCP would be in charge of making the right link, even on Windows with junctions for instance)

Answer 2

It sounds like you need to store your preferences at a central location that all users/machines can reach. This means you have to implement your own IPersistentPreferencesStore . Then you can override org.eclipse.jface.preference.PreferencePage#doGetPreferenceStore() to use it.

The bigger question is how to implement that central preferences store, but that depends on the technologies you are using. In general, if your project uses a central server, you probably should store your preferences there. For example, if your project already uses a relational database, one solution would be to create appropriate database tables and implement IPersistentPreferencesStore to access those tables via JDBC.

Answer 3

You should read about multi-user installs

In our case we have separated the per-user preferences from the application configuration by setting the config.ini to include the following:

osgi.instance.area=@user.home/Application Data/earthrise
osgi.configuration.area=@user.home/Local Settings/Application Data/earthrise/144/configuration
osgi.sharedConfiguration.area=c:/program files/earthrise/configuration
osgi.configuration.cascaded=true

The result of this is that any preferences set by the user are stored in their roaming profile, but application specific configuration data is stored in the Local Settings.

This doesn't solve the problem of having user preferences specific to a particular workstation, but does allow to have each user to have their own preferences.

A catch with this is that the eclipse error log file will be stored in the instance area and get carried around in their roaming profile - not really what you want. You can code around this in the plug-in. See the workaround at eclipse bugzilla - search for 256502

Answer 4

Just a thought!

Since the load() method of PreferenceStore does:

public void load() throws IOException {
    FileInputStream in = new FileInputStream(filename);
    load(in);
    in.close();
}

and you can either create a PreferenceStore

PreferenceStore(String filename)

or set its file name

public void setFilename(String name) {
    filename = name;
}

you might be able to "hack" the file name to some place on a shared server (or the users shared home folder perhaps)...