Community
Participate
Working Groups
From the review of the runtime refactoring... We would like to get rid of the core.runtime.Preferences class. We need to make sure we have a good story going forward though. People should be calling the IPreferencesService search methods. When reviewing IPreferencesService we noticed that setting the search order for scopes is not thread safe. You set the search order and then later get prefs from the service. If 2 people set different search orders, then there is a problem. Consider changing the IPreferencesService search methods to take an explicit list of contexts to search to prevent this problem. We considered this when originally designing the service but decided against it. We need to re-visit the reasons behind the design.
Moving bugs from code review out of inbox
Removing milestone (we're past M5)
Created attachment 36417 [details] new class - ScopedPreferences Here is an attempt at making things simplier as well as thread safe. Here is some sample code which uses the new class. The questionable thing is specifying the search order. We want to make this as easy as possible for clients. Have also thought about creating a SearchOrder class, etc but thought that just an array is simpliest. Thoughts? ---------- List list = new ArrayList(); IProject project = ResourcesPlugin.getWorkspace().getRoot().getProject("foo"); list.add(new ProjectScope(project)); for (int i = 0; i < ScopedPreferences.DEFAULT_ORDER.length; i++) list.add(ScopedPreferences.DEFAULT_ORDER[i]); IScopeContext[] order = (IScopeContext[]) list.toArray(new IScopeContext[list.size()]); ScopedPreferences preferences = new ScopedPreferences(BUNDLE_ID, order); return preferences.get("key", "defaultValue");
More information: The original method that was causing us problems was #setDefaultLookupOrder. When you set the default lookup order, you actually set it at the granularity of a qualifier or qualifier and key pairing, NOT for all qualifiers. So there is really only an issue if 2 clients are setting the default lookup order for the same plug-in id, at the same time. That being said, here is another alternative to adding a new class. Essentially we want to change the semantics of the scope context parameter in the search methods: get(qualifier, key, default, IScopeContext[]) Currently the contexts are optional, the order is irrelevant and they are only used as hints to find the real preference nodes as set by the default lookup order. Essentially we want to be able to say that the array of scope contexts that you pass in, is the exact search order to be used during lookup and the default lookup order should not be consulted. - create a new empty interface called IScopeOrder - have IScopeContext extend IScopeOrder - in the implementation of #get: if (contexts instanceof IScopeOrder) { // use the exact order as specified } else { // we have IScopeContexts so perform the old lookup } So now client code would look like: contexts = new IScopeOrder[] {...} instead of: contexts = new IScopeContext[] {...} Also note that minimally for 3.2 we need to update the javadoc for #setDefaultLookupOrder warning clients that there may be thread safety issues.
Here is another alternative to adding a new class/interface. We again change the semantics of the scope context array parameter to the search methods. In this case, the first arguement is a marker to indicate whether or not the array specifies the search order. Constant defined: public static final IScopeContext EXACT = new InstanceScope(); Service search method Impl: // note: use == here and not equals() if (contexts[0] == EXACT) { // then use the specified contexts as the exact search order } else { // otherwise use the contexts as hints and use the default lookup order }
Personally I prefer the approach in comment 5 at this point. It is a bit more hacky but it does not introduce a new type/concept. That approach feels more confusing in the long run. In 3.3 we should revisit this and see about some new API. DJ, do you want to open an new bug for 3.3?
-1 for 3.2. The scope of this problem is not a broad as originally feared as typically it is only a bundle itself that is accessing its own preferences and setting up the search order. We should however as part of 3.3 look to rationalize this. In fact, we should look to standardize scopes and searching in OSGi as extensions to the OSGi preference service.
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. -- The automated Eclipse Genie.
No plans to move this forward.
