Community
Participate
Working Groups
In Enterprise RCP Applications it must be possible to store all persistent settings such as dialog settings and workbench settings collected with the memento mechanism according to a user. Assumption: All users share the same workspace location! It is already possible to code a own store/restore strategy for dialog settings if you extend the AbstractUIPlugin class. But it would be a better solution to register a handler that takes over the store/restore step for the workbench state file and the dialog settings files. E.g. In the case of the dialog settings we extend the default file name with the login id of the user that is currently using the application. A even better solutions would be, if all these settings are stored and restored from a database together with other user specific information. thanks Stefan Lötscher, Inventage
Eclipse is not currently architected to support per-user settings in the same workspace. In addition to preferences and dialog settings, plug-ins often assume that they can store per-user data in the plug-in's local metadata area. The only way to guarantee per-user state currently is to have separate instance locations (aka workspace locations) for each user, and to restart when switching users.
(In reply to comment #1) To precise how these kind of applications are used, here a use case: - The workstation user starts the rcp application. - A login dialog appears with a free user id field and a password field. - The user enters a user id "A" and a password. - The application gets the user information, such as the user profile, roles and default settings from the server according to the user id "A". - The rcp application opens the workbench. All settings should be identical to the ones from the last session of that specific user. - The user does his work. - The user closes the rcp application. - All settings are stored according to user id "A" on the server. - The workstation user starts the rcp application and logs in with another user id "B". He expects specific settings for the user id "B" from the last session of "B".
So just to clarify: you don't need to switch users within the same session, but you do want all user settings to be persisted on the server?
(In reply to comment #3) Yes! I think it is not necessary to switch the user within a session. If this behaviour would be a requirement, we add the functionality to restart the application analogous to the "Switch workspace" action in the IDE.
One option would be to export prefs to the server after workbench shutdown, and import them before workbench startup. MvM, can you provide pointers to the API? For dialog settings, we'd need to provide a similar service in order to avoid plug-in activation.
CC'ing DJ from Core. you want to take a look at: Platform.getPreferencesService() and the IPreferencesService interface. The preferences import/export support makes use of it heavily in the org.eclipse.ui.workbench plugin in package org.eclipse.ui.internal.wizards.preferences
If you can accept this data being stored locally, I would say the easiest approach is to set the workspace data location after the login prompt. I.e., use a different platform metadata location (aka workspace location) per user. The platform is designed so that it can startup without a data location, and have one set by the workbench advisor after an initial login dialog. That would ensure you get metadata for all plugins stored on a per user basis. Otherwise, you would have to get hooks into every plugin that stores metadata in the workspace location (via workspace level preferences, or otherwise).
(In reply to comment #7) This approach is half the way that we would like to go. The goal is that the user has the posibility to start the application anywhere in an enterprise without loosing his dialogsettings, view positions or preferences. Another scenario is that the user has to setup his computer e.g. after a harddisk crash without loosing any data. As a first step we will implement your idea.
Reassigning bugs in component areas that are changing ownership.
Prakash is now responsible for watching bugs in the [RCP] component area.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
