Community
Participate
Eclipse IDE
When the preferences are first initialized in the start method of the plugin that contains the product/application that is started, the stored preferences are not reloaded. See the attached example plugin, source TestPlugin.java, line 36. Release 3.0.1 works correctly and reloads the preferences from the file store. This seems to happen only for the plugin that contains the product to run, other plugins are reloading the preferences correctly. Tested with RCP 3.1M5a not sure about previous releases. I have included the config.ini used with RCP 3.0.1 and 3.1.0 just in case it is a problem with it.
Created attachment 18334 [details] Test plugin
I will need more information about the problem that you are experiencing. The test plug-in that you include doesn't really explain the problem to me. Also I am not sure what you mean by "the stored preferences are not reloaded". In the example plug-in you are setting the default values for certain preferences and I see them being set, but I don't see where you are trying to access the values in the store.
I'll try to explain better the steps needed to see the problem. Start the RCP 3.1.0 with the given test plugin, open Window -> Preference, write something in the Test preference field. Close the program. Open it again. Reopen Window -> Preference and you'll see that the preference field is empty. The preference file under workspace\.metadata\.plugins\org.eclipse.core.runtime\.settings shows that the preference was written correctly, but not reloaded. The setting of the default property isn't much relevant to the problem (I wrote it as a test and being different from the preference set in the preference page was intentionally), I discovered later that the problem is caused by the getPreferenceStore() call. If you remove this call, the preferences are reloaded correctly. If you try the same steps using RCP 3.0.1 you'll see that it works as expected.
Hmm...this works OK for me. My steps: - add your plug-in to my workspace - run a runtime workbench selecting your app as the application - Window -> Preferences -> Preferences - set the value - hit OK - shut down runtime workbench - start the runtime workbench - Window -> Preferences -> Preferences - value is in the text field Is there something that I am missing?
> Hmm...this works OK for me. My steps: > > - add your plug-in to my workspace > - run a runtime workbench selecting your app as the application No, this way it works. The problem occurs only if the application is run as a standalone app.
This looks to be a problem with accessing the preference store before the instance location has been set. We've seen this before. Basically what is happening: - application starts - application accesses the preference store - store tries to load values - workspace location is not set yet so we can't load the values - application sets the workspace location - preferences are already considered to be loaded so the stored values are not reloaded This doesn't happen in a runtime workbench because the workspace location field is always set. Temporary work-around is to pass "-data <workspaceLocation>" into the application as a command-line arg. Jeff, when/where is the instance location set for an RCP app?
A question: As a plug-in developer, when you are storing preference values in your preference store, where would you expect them to be saved? Keep in mind that you are writing an RCP application and you don't have a "workspace".
Removing Jeff from CC list. My mistake, the instance location is never being set. Setup to replicate in a runtime workbench: - add your plug-in to workspace - set up new launch config and set application to be com.maccasoft.test - set the data location to be "@nodefault" - under Plugins, de-select everything and then only select com.maccasoft.test and its required plug-ins The reason that I ask the question in comment #7 is that you are creating a preference page and populating it with values, and then saving the values but to where?
I think that there are some basic misunderstanding, because I see that the workspace is always created and, as I said in comment #3, I can read the preferences stored in <rcp_folder>\workspace\.metadata\.plugins\org.eclipse.core.runtime\.settings. It is maybe the use of the org.eclipse.update.configurator plugin ? Maybe it occurs only on Win32 ? In any case, the same settings are working with RCP 3.0.1, so something was changed in the middle.
See also bug 87892.
*** Bug 101474 has been marked as a duplicate of this bug. ***
I just encountered this bug in context of bug 101474 and it's a real doozy. This makes developing RCP apps VERY difficult - you need to jump through (currently) undocumented hoops to make preferences work in your exported app. I cant believe this hasn't kicked the ass of other RCP developers already.
The workaround is to call getStateLocation() from within the application plug-in's start method. This forces creation of the workspace before any preferences are accessed. E.g. public class RCPAppPlugin extends AbstractUIPlugin { public void start(BundleContext context) throws Exception { super.start(context); getStateLocation(); } // ... }
Like Nick mentions, the problem is that the plug-in asks for the instance preferences before the workspace is created. It is easily reproducible by running with -@nodefault and accessing the instance preferences in the plug-in startup code. At one point when the client asked for the instance preferences where there was no data location, we threw an exception but this was deemed too harse so this code was removed. So the question becomes: if you are running without a workspace and you store preferences, where do you expect them to be stored?
*** Bug 87892 has been marked as a duplicate of this bug. ***
I think the problem case is when there is a default location (i.e. what you get when you run eclipse with no -data argument). The expected behaviour is: - if no explicit workspace is specified, but there is a default for it, - when a preference is set, then the corresponding store is saved on shutdown (if not forced earlier by the app), - the pref is restored on startup I believe this is not happening because the prefs mechanism detects the case where the workspace has not yet been created, and will not force it, but this puts it in a state where it will not save the prefs on shutdown.
I also don't know of any way of replicating the "no -data but with a default" state when self-hosting.
Nick, DJ, this is a critical bug because it manifests itself in a bad way in intro. the WorkbenchWindowAdvisor.openIntro() method relies on preferences to store and reload Intro's life cycle. With this defect, an Intro is coming up on each launch of the rcp app ! to reproduce, export a simple rcp app that has an intro, and check that intro comes up each time, even if you shutdown with the intro view closed. I wonder if the rest of the workbench has its state saved and reloaded correctly?
No, it doesn't. The entirety of the workbench(relating to preferences) is hosed in this scenario. We may have a fix for this bug...
Er, I didn't mean to change the owner.
Created attachment 26480 [details] Patch against org.eclipse.ui.workbench Patch that modifies AbstractUIPlugin.getPreferenceStore to ensure that the instance location is set prior to the store creation if there is a valid instance location.
I'd appreciate any interested parties taking a look at this patch. It seems to cover all instance locations - @none, @noDefault, and valid path.
Kim, and all interested parties, the patch does not solve the bug, at least in the use case that I have. I might have tried something incorrecly, so please speak up. here is what I tried: Scenario one: I applied the patch to o.e.ui.workbench R311 M stream. Self hosted with -data @nodefault Workbench state is saved and remembered. Great, patch did not break anything. Scenario two: with the applied patch, created a Hello World RCP app. self hosted, state is not remembered. Question, with a simple RCP app and a @nodefault option for the instance location, where will the workspace be really created? Shoudl the workspace location be programatically set?
With @nodefault the behaviour should be the same as before. The application has to set the location before any preferences are called. I think this is reasonable...
I tried the patch, and it worked for me, both when running the generated RCP app from within Eclipse, and after exporting it using the Export Product wizard.
Created attachment 26595 [details] patch against org.eclipse.core.runtime I would propose fixing the problem using this patch rather than changing code at the UI level. The change I propose is to InstancePreferences.getBaseLocation(). This method currently only returns a location if the instance location has been set explicitly (this was put in to fix bug 69386). I think that the existing test is too strong - if the location allows a default, this default should be used, even though the location has not been set explicitly.
Why does EclipsePreferences.load(IPath location) fail silently if the location is null? Can't it (for example) put a warning in the log file so that it's easier for RCP developers to see why preferences are not loaded?
*** Bug 107698 has been marked as a duplicate of this bug. ***
I'll check out the patch. Thanks Boris. EclipsePreferences#load doesn't log anything because it is my implementation of te preference interfaces and in my case it is valid for a preference type not to have a location on disk. One such implementation is the "test" scope that is shipped with the test suites.
I would like to suggest that this be fixed in 3.1.1 (regardless of the level at which we fix it). Any RCP application that uses preferences but does not set the workspace location explicitly will see this.
+1 for fixing in 3.1.1, DJ?
I concur that it should be fixed in a release patch rather than delaying until 3.2. This simple bug could kill early adoper interest in RCP, and it keeps cropping up on the newsgroups.
+1 for 3.1.1. I have tested the core changes against Marco's original test plug-in and it works. I have released the core change into the 3.1.x maintenance stream and HEAD. Closing.
Verified using the steps from bug 107698 on Windows XP, build M20050923-1430.
Does the fix allow preferences to be restored in an RCP app that has no Plugin class? Also, is there a code workaround for that case under 3.1.0 or 3.1.1?
re comment #35: By no plug-in class, do you mean that the plug-in containing the application does not have a plug-in class? The patch will still work in that case. One possible workaround would be to set the workspace location in your application's run method.
