Community
Participate
Working Groups
A user is running RSE on multiple UNIX machines, sharing the same workspace through a network file system on all those machines. Starting RSE first on machine A, generates a default private profile named A. Starting RSE on machine B now, ensureDefaultPrivateProfile() uses profile A because it is marked "default private". But getDefaultPrivateSystemProfile() returns null, because no profile with name B exists. This is inconsistent. It is unclear, how programmatic access to RSE should treat the default private system profile in such a scenario. Javadoc does document getDefaultPrivateSystemProfile() correctly as it works now, but this way is currently questionable. This also shows in the usage where getDefaultPrivateSystemProfile() is used: on host B, several functionality of RSE will not be available because it returns null (e.g. systemSearchPage will not find a default host to search). We'll need to understand and specify what exactly we mean by the "default private system profile" and how it is intended to be used. Dave can you give a comment on this?
Currently Javadoc says this: /** * @return the default private profile created at first touch. * Will return null if it has been renamed. */ public ISystemProfile getDefaultPrivateSystemProfile(); Perhaps it would be sufficient to tell clients what they should do in case they get null, and that they can get null in any of the following cases: * default private profile has been deleted (while running rse, i.e. after ensureDefaultPrivateProfile has been called) * default private profile has been renamed * We're running on a different host than the original one on which the default private profile had been created I think it would make sense if RSE profile manager could ensure that at any given time, there is exactly one active "default private" profile. But we should discuss this.
Created attachment 78624 [details] ensure the same default private profile for all clients i did some changes on the SystemProfileManager that should solve the problem of different private system profiles. the private system profile is now "calculated" when ensureDefaultPrivateProfile is called. getDefaultPrivateSystemProfile() always returns this profile (and can never return null up to now). the algorithm to "calculate" the default private system profile does the following: - take the list of all active profiles (without the team profile) - first of all the profile with the machines name is used when - it is the only one, - it is marked as default private, - or no other profile is marked as default private - otherwise the first profile marked as default private is used - otherwise the first available profile is used - otherwise no profile exists, so a new one with the machines name will be created the used profile will be marked as default private, all other profiles will be marked as NON default private additionally i removed some unused private methods from the SystemProfileManager.
We'll probably need to discuss this again, but from the discussions we've had so far my understanding is this: 1.) The attribute that's persisted with the profiles ("isDefaultPrivate()") is not named correctly. It should better be named "isPrivate()" indicating that it should not be team-shared. We cannot make the renaming now since it would be an API change, but we should understand that this is the real meaning of this attribute. In an environment of multiple profiles and persistence providers, which can be made active/inactive, we cannot really guarantee that one given profile is the "default". Being the default or not can only be done dynamically, but it cannot be persisted. 2.) The persisted attribute should not be changed. It is a property of the profile, indicating how it was generated (automatically) and that it is not meant to be team-shared. You cannot go and set/reset this. 3.) I think that de-activating the default private profile does not make sense (it should always be active, the UI should even forbid de-activating it). Therefore, I think the algorithm for finding the default private profile should be allowed to activate a private one if it finds one. Because of this, I think the algorithm needs to be different: * Assemble a list of all profiles marked "private". * If it contains the profile with current host name, this is the default private one. Activate it if necessary. * Otherwise, the first active one is default private. * If no active one, the first one is default prrivate. Activate it. If the list was empty, create a new profile: - Try current host name; modify the name by appending a number until no profile is found by that name which is not marked private.
getDefaultPrivateSystemProfile now returns the same profile as that which was ensured. Fixed with bug 222376. *** This bug has been marked as a duplicate of bug 222376 ***
I don't think it's a good idea to mark an API-bug as duplicate of a non-API bug. This could give the impression that the API change has not been made (because it's a duplicate of some other API change request somewhere). Better mark it as dup the other way round.
Fixed with bug 222376.
Tobias can you review and verify the fix please.
Dave: With your current code, what happens if the user makes the default private system profile inactive? It's probably not possible by UI but I think the API should also ensure that either this cannot happen, or the default private profile is chosen again just as if a profile is deleted. Reopen to clarify.
Good question. I think the API should make sure this cannot happen. This should probably hold true as well for delete.
Updates include comments in the javadoc for various levels of deletion and set activation. Actions for delete and activate were modified to disable them when the selected profile is the default profile.
Added testcases for profiles
Comment on attachment 78624 [details] ensure the same default private profile for all clients Patch is obsolete since this was fixed differently as per comment 4.
