Community
Participate
Working Groups
Build Identifier: M20090211-1700 Our product uses preferences that exist both on the workspace and project level. The issue arises when a preference has the default value set. If the user sets the value of a preference in the instance(workspace) scope to a value other than the default one there is no way to override this value in the project scope with the value that is also the default value. This is caused by the way setValue methods are implemented in ScopedPreferenceStore. The methods check whether the new value and the default value are the same, and remove the value if they are. For example, let's assume there's a String preference "name" whose default value is "George". Now, the user sets the value of "name" to "John" in the Instance scope. The user then decides he wants to override the value of "name" in one of his projects, setting it to the value of "John". The set code in ScopedPreferenceStore ignores the set because "John" is also the default value. If the user now does a getString("name") he gets back the value from the Instance scope "George" instead of the expected value "John". Reproducible: Always
I've made a mistake in my example description. I'm not sure how to edit the description, so here is the corrected text... For example, let's assume there's a String preference "name" whose default value is "John". Now, the user sets the value of "name" to "George" in the Instance scope. The user then decides he wants to override the value of "name" in one of his projects, setting it to the value of "John". The set code in ScopedPreferenceStore ignores the set because "John" is also the default value. If the user now does a getString("name") he gets back the value from the Instance scope "George" instead of the expected value "John".
Could you provide a code snippet that shows the problem?
The ScopedPreferenceStore class keeps track of the scope to set values on (in your case the "project" scope) and when it sets the value, it just checks that scope and doesn't do a proper lookup taking other scopes into consideration. (like #internalGet for example) I *think* a fix might be: if (internalGet(name) == value && getDefaultBoolean(name) == value) { getStorePreferences().remove(name); } else { getStorePreferences().putBoolean(name, value); } Note that this will have performance considerations because we are now doing more lookups.
Oleg, Here's the requested code snipped that reproduces the problem... final String qualifier = "scoped.preference.test"; String paramName = "language"; InstanceScope instanceScope = new InstanceScope(); ScopedPreferenceStore instanceStore = new ScopedPreferenceStore(instanceScope, qualifier); instanceStore.setDefault(paramName, "English"); instanceStore.setValue(paramName, "Japanese"); ProjectScope projectScope = new ProjectScope(project); ScopedPreferenceStore projectStore = new ScopedPreferenceStore(projectScope, qualifier); projectStore.setSearchContexts(new IScopeContext[] { projectScope, instanceScope }); projectStore.setValue(paramName, "English"); System.out.println("Default language is " + projectStore.getDefaultString(paramName) + "; Language set in Instance scope is " + instanceStore.getString(paramName) + "; Language set in Project scope is " + projectStore.getString(paramName)); Expected result is "Default language is English; Language set in Instance scope is Japanese; Language set in Project scope is English" Actual result is "Default language is English; Language set in Instance scope is Japanese; Language set in Project scope is Japanese"
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.
