Community
Participate
Working Groups
It would be nice to store the OSGi preferences where they are accessible from the Eclipse preference API. That way a bundle that uses preferences can decide which API they feel like using to get at their preferences.
Created attachment 33151 [details] Patch to org.eclipse.equinox.preferences Stores OSGi preferences in eclipse preferences. OSGi "System" prefs are stored under the key <bundle-symbolic-name>/system. OSGi "User" prefs are stored under <bundle-symbolic-name>/user/<user-name>.
Its important to note that the OSGi "system" and "user" prefs are stored in the "instance" scope of the Eclipse preferences. This equates to the data location so if you have an RCP app with no data location I don't think it will work. Should we be creating a new scope to store the preferences in?
Yes, I was unsure on that point. Would it be more appropriate to use the "configuration" scope?
I think that would be a better choice. Jeff, do you have a preference (no pun intended) between config prefs or in a new location?
Hmmm, great question! It pretty much depends on the expected scope for normal OSGi prefs. This is similar to Bundle.getDataFile() vs. Plugin.getStateLocation() (the names may be wrong but you know what I mean I hope). Note that if you use the bundle-symbolic name then two versions of the same bundle share the prefs. This could be cool but may also may be a bummer. Similarly, if you use the bundle id (the long) then you get into challenges with uninstall/install vs. update and issues when you run -clean. The direction on the above will likely dictate the scope that should be used.
The attached patch uses bundle symbolic name if available, and then falls back to bundle-id if there is no symbolic name.
From OSGi-dev: > How should an implementation of the OSGi preferences service handle > bundles with the same symbolic name but different versions both > running on the same system? Should the bundles share the same > preferences or should they each have their own? Technically, these are 2 distinct bundles. Each has a distinct bundle id and bundle location. Therefore, Prefs must treat each as a seperate bundle and give them each their own preferences. If the there was only one bundles installed and it was updated to a new bundle version, then the updated bundle would then use the prefs from the original bundle. This is because they are the "same" bundle to Prefs: they have the same bundle id and bundle location. (BJ Hargrave)
Created attachment 34460 [details] Updated patch to org.eclipse.equinox.preferences Updated patch - stores OSGi prefs data in the "configuration" scope keyed under bundle id as described above.
Word on the street (a street in Austin...near's Tom's house :-) is that when Eclipse does a bundle update, it actually does an uninstall and then an install which would assign a new bundle id. Is this going to cause us problems?
I just talked this over with Tom. The short answer is yes this will cause problems, but we'll just have to tolerate them as a known limitation. The OSGi spec says that a bundle should have the same bundle id for it's entire lifecycle, including updates and framework restarts. However you are right that Eclipse update uninstalls and then reinstalls an updated bundle, resulting in a new bundle id. I think ultimately we have to look at this from two use cases: 1) Eclipse - in the Eclipse use case Eclipse plugins will use the Eclipse preferences api to store their preferences. When Eclipse updates the plugins the updated plugins can see their old preferences because the preferences are keyed off of a "qualifier" which is usually the plugin id (aka bundle symbolic-name). 2) OSGi - in the OSGi use case OSGi bundles will use the OSGi preferences service to store their preferences. When OSGi updates the bundles (e.g. the console 'update' command or bundle.update(...)) the updated bundles will see their old preferences because they will have the same bundle id. The caveat is the "hybrid" use case where we update OSGi-type bundles using the Eclipse update mechanism. In this case the updated bundles will not see their old preferences because they will not have the same bundle id. I think we will have to keep this as a known limitation for now.
Not much has happened since Roy's last comment. DJ can this happen for 3.2? Jennifer is this critical for your scenarios?
Yes, this is critical from my standpoint. We need to be able to manage the OSGi Preferences as Eclipse Preferences.
Sorry, I missed this in my bugzilla bucket. Yes we will release this patch but its too late for RC2. I will review it and we'll try and put it in early next week in time for RC3.
get your votes out soon if this is going to be released...
+1 DJ, do we have the correct approvals to get this in?
DJ and I to review the code for RC3.
Patch looks good to me. (once applying changes to update the copyright, formatting, and organize imports of course :-)
+1 The OSGi TCK passes with the patch applied.
+1 ship it!
Consider it shipped. [contributed patch applied]
Wassim, as team lead can, please give approval for this fix. It has been review by serveral team members and does not effect normal Eclipse Preferences clients. It only effects clients of the OSGi preferences service implementation which was new to 3.2. Thanks.
+1 for RC3.
adding "contributed" keyword to patches contributed by the community.
