Currently a common patterns is that one acquires the instance scope through a static access InstanceScope.INSTANCE and then pass the ID of the bundle to listen for preference changes.
Another similar call is Platform.getStateLocation(...) or Plugin.getStateLocation to get an IPath to store bundle specific data.
Both calls suffer from the fact (due to their static access) that they are prone to initialization order problems, e.g. if the workspace location is not set. Beside that, a user of these must in one way or another bind itself to the Platform and/or Plugin activator to work where a reference to IScopeContext / IEclipsePreferences would be enough.
I'd thus would suggest the following:
There is a (private) BundleStateScope that register a IScopeContext service factory that creates a BundleStateScope passing the requesting bundle
The IScopeContext.getNode(String) method uses InstanceScope.INSTANCE.getNode(bundle.getSymbolicName()).node(qualifier)
The IScopeContext.getLocation() returns MetaDataKeeper.getMetaArea().getStateLocation(bundle)
That way a component that want to use either of both could simply use:
to get a reference and then call to add a preference listener to the root:
scopeContext.getNode("").addPreferenceChangeListener(this);
or
IPath myLocation = scopeContext.getLocation();
to get hold of its state location.
Given that we delay the registration of the service factory until a suitable state is reached (e.g. workspace URL set) such a component is resistant to start-order dependencies or to early bundle activation.
Currently a common patterns is that one acquires the instance scope through a static access
InstanceScope.INSTANCEand then pass the ID of the bundle to listen for preference changes.Another similar call is
Platform.getStateLocation(...)orPlugin.getStateLocationto get an IPath to store bundle specific data.Both calls suffer from the fact (due to their static access) that they are prone to initialization order problems, e.g. if the workspace location is not set. Beside that, a user of these must in one way or another bind itself to the Platform and/or Plugin activator to work where a reference to
IScopeContext/IEclipsePreferenceswould be enough.I'd thus would suggest the following:
IScopeContextservice factory that creates a BundleStateScope passing the requesting bundleIScopeContext.getNode(String)method usesInstanceScope.INSTANCE.getNode(bundle.getSymbolicName()).node(qualifier)IScopeContext.getLocation()returnsMetaDataKeeper.getMetaArea().getStateLocation(bundle)That way a component that want to use either of both could simply use:
to get a reference and then call to add a preference listener to the root:
scopeContext.getNode("").addPreferenceChangeListener(this);orIPath myLocation = scopeContext.getLocation();to get hold of its state location.Given that we delay the registration of the service factory until a suitable state is reached (e.g. workspace URL set) such a component is resistant to start-order dependencies or to early bundle activation.