|Cannot set osgi property using RAP launcher [message #1107535]
||Thu, 12 September 2013 14:58
| Mark Leone
Registered: April 2012
I have a RAP app that implements a custom SettingStore. I implemented the SettingStore and its factory, and declared the factory using extension point org.eclipse.rap.ui.settingstores. All that's left to make it work is to set the OSGI property org.eclipse.rap.rwt.settingStoreFactory to point to the ID of my SettingStoreFactory.|
But I can't find any way to set this OSGI property using the RAP launcher. I edited the config.ini file at the location indicated on the Settings tab of the RAP launcher, in the "Configuration Area" section. I tried using the default location and also specifying a custom location.
In either case, the config.ini file is blown away and re-created each time I launch the app (and I do not have selected the option to clear the configuration area before launching). The launched app uses the default SettingStore instead of the custom one, and when I look at the config.ini file after launching, the entry that I placed there for org.eclipse.rap.rwt.settingStoreFactory is gone.
So what is the right way to set an osgi property when using the RAP launcher?
|Re: Cannot set osgi property using RAP launcher [message #1107951 is a reply to message #1107742]
||Fri, 13 September 2013 05:47
| Ivan Furnadjiev
Registered: July 2009
Somehow we forgot to rename the OSGi SettingStoreFactory property in RAP
2.0 (only documentation was wrongly updated).
RAP Tools version should match your RAP Runtime. Most of the changes in
RAP Tools correspond to changes in Runtime. Definitely, you will run
into problems when you are using RAP Tools 2.1 with RAP Runtime 1.5 (a
lot of properties/packages have been renamed).
On 9/13/2013 12:49 AM, Mark Leone wrote:
> Thanks, Ivan. That was it! I should have mentioned that I'm using RAP
> 1.5 (I'm porting the app to RAP 2.1, but have to make some changes
> quickly to the current version before getting back to porting).
> So did they add the "rap" component to the property name in RAP 2.0
> and then remove it again in RAP 2.1? Or is it perhaps because I'm
> using RAP tooling 2.1? My RAP runtime is 1.5, but I have to use the
> property name without "rap" to get it to work.
> As documented in a
> I installed the feature in Juno that upgraded RAP tooling to 2.1, and
> then I was not able to revert back to 1.5 Tooling when I switched my
> runtime from 2.1 back to 1.5. I'd have to remove a feature which
> contains the entire platform. Maybe I'm going to run into other
> problems using 2.1 Tooling with a 1.5 runtime?
Professional services for RAP and RCP?
|Re: Cannot set osgi property using RAP launcher [message #1108464 is a reply to message #1107951]
||Fri, 13 September 2013 22:26
| Mark Leone
Registered: April 2012
I downgraded my RAP tooling to match the runtime, and corrected the SettingStoreFactory property, and now the custom SettingStoreFactory is being loaded. I'm seeing something very strange when using it however.|
I create a preference store as follows:
preferenceStore = new ScopedPreferenceStore(new SessionScope(), MyPlugin.getDefault().getBundle().getSymbolicName());
Looking at the code for ScopedPreferenceStore, I see that unless the IScopeContext passed as the first argument is an instance of SessionScope, the SettingStore will not be used. This is a non-API class, and the documentation says it can be instantiated. It seems there should be an API-compliant way to do this, but I see not other way to get an instance of SessionScope, and the SettingStore will not be used unless I pass an instance of SessionScope.
Whether my problem is related to the above or not, I don't know. But here's what's happening. I have a PreferencePage with FieldEditors. I set the PreferenceStore shown above as the PreferenceStore for the PreferencePage and for the FieldEditors. I call fieldEditor.load() to have the widget show the preference value, and I call fieldEditor.store() to persist the value set by the widget.
When I call fieldEditor.store() I see the values persisted in the data store that backs my SettingStore, as expected. But when I call fieldEditor.load(), with the same PreferenceStore set on fieldEditor as was set when I called store(), it returns null for the preference value. Stepping through the code in the debugger I see that the key by which the ScopedPreferenceStoreCore object is retrieved from the SessionStore (ScopedPreferenceStore line 164) is different when load() is called than when store() is called. For the former it is #session/<my plugin id>/<preference name>, and for the latter it is #store/<my plugin id>/<preference name>
I'm mystified why this would be different, when I call load() and store() on the same FieldEditor object with the same ScopedPreferenceStore backed by the same SettingStore.
Is there a better way to do this? Am I just doing it wrong?
[Updated on: Mon, 16 September 2013 21:15]
Report message to a moderator
Powered by FUDForum
. Page generated in 0.02415 seconds