Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse 4 » Saving addon state
Saving addon state [message #949936] Fri, 19 October 2012 09:07 Go to next message
Jeremy Stone is currently offline Jeremy Stone
Messages: 7
Registered: October 2012
Junior Member
We are currently investigating porting our Eclipse 3.x RCP application to use the new E4 framework and we are having difficulty saving and loading persistent state for an add-on configured as a model fragment in an extension plugin.

Initially we had essentially the following for an addon contribution class...

public class SomeAddonImpl{
private final MAddon addon;

@Inject
public Clusters(MAddon addon)
{
this.addon = addon;

// Get the state
state = addon.getPersistedState().get(someKey);
}

@PersistState
public void persist()
{
// Persist the state
addon.getPersistedState().get(someKey, state)
}
}

However persist() was never called when the application was closed.

To work around this we added a LifecycleManager with a @PreSave annotated method to fire off an event, and we modified our addon class's persist() method to subscribe to it.

With this change the workbench.xmi gets saved with our addon's updated state.

However the workbench state does not get loaded. The key is not present when we call getPersistedState() in our constructor. (Tried doing in a @PostConstruct method instead and still it did not work.)

We failed to find any complete examples of persistence of addon state anywhere. I presume it should work(??)

Any ideas?
Re: Saving addon state [message #952033 is a reply to message #949936] Sun, 21 October 2012 01:35 Go to previous messageGo to next message
Lars Vogel is currently offline Lars Vogel
Messages: 1048
Registered: July 2009
Senior Member

Looks like you using the getter in the place where you want to save. Wink
Re: Saving addon state [message #952037 is a reply to message #949936] Sun, 21 October 2012 01:37 Go to previous messageGo to next message
Lars Vogel is currently offline Lars Vogel
Messages: 1048
Registered: July 2009
Senior Member

Looks like you using the getter in the place where you want to save. Wink
Re: Saving addon state [message #952049 is a reply to message #949936] Sun, 21 October 2012 01:35 Go to previous messageGo to next message
Lars Vogel is currently offline Lars Vogel
Messages: 17
Registered: July 2009
Junior Member
Looks like you using the getter in the place where you want to save. ;)
Re: Saving addon state [message #952050 is a reply to message #949936] Sun, 21 October 2012 01:37 Go to previous messageGo to next message
Lars Vogel is currently offline Lars Vogel
Messages: 17
Registered: July 2009
Junior Member
Looks like you using the getter in the place where you want to save. ;)
Re: Saving addon state [message #952056 is a reply to message #949936] Sun, 21 October 2012 01:35 Go to previous messageGo to next message
Lars Vogel is currently offline Lars Vogel
Messages: 17
Registered: July 2009
Junior Member
Looks like you using the getter in the place where you want to save. ;)
Re: Saving addon state [message #952057 is a reply to message #949936] Sun, 21 October 2012 01:37 Go to previous messageGo to next message
Lars Vogel is currently offline Lars Vogel
Messages: 17
Registered: July 2009
Junior Member
Looks like you using the getter in the place where you want to save. ;)
Re: Saving addon state [message #952062 is a reply to message #949936] Sun, 21 October 2012 01:35 Go to previous messageGo to next message
Lars Vogel is currently offline Lars Vogel
Messages: 17
Registered: July 2009
Junior Member
Looks like you using the getter in the place where you want to save. ;)
Re: Saving addon state [message #952063 is a reply to message #949936] Sun, 21 October 2012 01:37 Go to previous messageGo to next message
Lars Vogel is currently offline Lars Vogel
Messages: 17
Registered: July 2009
Junior Member
Looks like you using the getter in the place where you want to save. ;)
Re: Saving addon state [message #952069 is a reply to message #949936] Sun, 21 October 2012 01:35 Go to previous messageGo to next message
Lars Vogel is currently offline Lars Vogel
Messages: 17
Registered: July 2009
Junior Member
Looks like you using the getter in the place where you want to save. ;)
Re: Saving addon state [message #952070 is a reply to message #949936] Sun, 21 October 2012 01:37 Go to previous messageGo to next message
Lars Vogel is currently offline Lars Vogel
Messages: 17
Registered: July 2009
Junior Member
Looks like you using the getter in the place where you want to save. ;)
Re: Saving addon state [message #952273 is a reply to message #952050] Sun, 21 October 2012 06:02 Go to previous messageGo to next message
Lars Vogel is currently offline Lars Vogel
Messages: 1048
Registered: July 2009
Senior Member

Sorry for posting the same thing x times, looks like my browser got crazy.
Re: Saving addon state [message #953418 is a reply to message #952273] Mon, 22 October 2012 04:24 Go to previous messageGo to next message
Jeremy Stone is currently offline Jeremy Stone
Messages: 7
Registered: October 2012
Junior Member
Sorry - that's just a typo in the snippet posted. The persist() method should have read...

@PersistState
public void persist()
{
// Persist the state
addon.getPersistedState().put(someKey, state)
}


The workbench.xmi does get updated but the persisted state does not load. In our constructor, where it does the get(someKey), the value for the key is null (unless we set a default value in the persisted state for the addon in the fragment.e4xmi, in which case this default value is retrieved).
Re: Saving addon state [message #956164 is a reply to message #949936] Wed, 24 October 2012 05:37 Go to previous messageGo to next message
Jeremy Stone is currently offline Jeremy Stone
Messages: 7
Registered: October 2012
Junior Member
Lars,

Have created a simple couple of projects that exhibit this (see attached zip file).

The extension project (com.cyclone.e4.persist.extension) contains an addon class (PersistentAddon) which, when it starts up (via @PostConstruct), prints its state.

It also contains two methods to persist some state:
* one method annotated @PersistState. This does not fire when the appication is closed down hence...
* another method that accepts a lifecycle event from the lifecycle manager deployed in the main product project. This does fire and the state is stored in the workbench.xmi.

Running the program a second time shows that the state is not loaded.

So essentially two problems:
* Why does the @PersistState method not get called?
* Why is the updated state not available (despite it being saved in the workbench.xmi)?

Are we missing something?
Re: Saving addon state [message #956318 is a reply to message #956164] Wed, 24 October 2012 08:08 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas Schindl
Messages: 5013
Registered: July 2009
Senior Member
@PersistState only works on Parts! Could you please file a bugzilla so
that we update the JavaDoc please!

Tom

Am 24.10.12 11:37, schrieb Jeremy Stone:
> Lars,
>
> Have created a simple couple of projects that exhibit this (see attached zip file).
>
> The extension project (com.cyclone.e4.persist.extension) contains an addon class (PersistentAddon) which, when it starts up (via @PostConstruct), prints its state.
>
> It also contains two methods to persist some state:
> * one method annotated @PersistState. This does not fire when the appication is closed down hence...
> * another method that accepts a lifecycle event from the lifecycle manager deployed in the main product project. This does fire and the state is stored in the workbench.xmi.
>
> Running the program a second time shows that the state is not loaded.
>
> So essentially two problems:
> * Why does the @PersistState method not get called?
> * Why is the updated state not available (despite it being saved in the workbench.xmi)?
>
> Are we missing something?
>
Re: Saving addon state [message #956463 is a reply to message #956318] Wed, 24 October 2012 10:30 Go to previous messageGo to next message
Jeremy Stone is currently offline Jeremy Stone
Messages: 7
Registered: October 2012
Junior Member
Thanks Lars,

Would be happy to raise bug regarding the docs, but unsure why there is this inconsistency in the API. All MApplicationElement sub-interfaces have getPersistedState() (and this seems to get written to the workbench.xmi if entries are placed into it), so why not handle persistence in the same manner using the same annotation?

As things stand, is there a recommended way to trigger non-part elements to save their state? (A lifecycle event works, but seems to be a bit of a hack.)

Also why, when the state is saved, is that state not re-loaded? (This is the bit for which we have no work-around at present.)
Re: Saving addon state [message #958836 is a reply to message #956463] Fri, 26 October 2012 04:49 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas Schindl
Messages: 5013
Registered: July 2009
Senior Member
Why aren't you simply pushing the value to the persisted state once you
know it changed?

The annotation only makes sense on elements who come and go (like the
part is one) but not for things like an Addon who come and never go.

Please also note the package the annotation is coming from. It is named
....ui!

Tom

Am 24.10.12 16:30, schrieb Jeremy Stone:
> Thanks Lars,
>
> Would be happy to raise bug regarding the docs, but unsure why there is
> this inconsistency in the API. All MApplicationElement sub-interfaces
> have getPersistedState() (and this seems to get written to the
> workbench.xmi if entries are placed into it), so why not handle
> persistence in the same manner using the same annotation?
>
> As things stand, is there a recommended way to trigger non-part elements
> to save their state? (A lifecycle event works, but seems to be a bit of
> a hack.)
>
> Also why, when the state is saved, is that state not re-loaded? (This is
> the bit for which we have no work-around at present.)
Re: Saving addon state [message #964139 is a reply to message #949936] Tue, 30 October 2012 05:35 Go to previous messageGo to next message
Jeremy Stone is currently offline Jeremy Stone
Messages: 7
Registered: October 2012
Junior Member
Thanks Tom...

Quote:
Why aren't you simply pushing the value to the persisted state once you
know it changed?


Yes we could do that - although a lifecycle event to persist when the application closes works for us. (Framework support akin to @PersistState would have been nice.)

Quote:
The annotation only makes sense on elements who come and go (like the
part is one) but not for things like an Addon who come and never go.


We use an addon to provide state across multiple views. Since the MAddon interface has persisted state exposed this seemed a good fit. And the state does get persisted to workbench.xmi.

However the issue remaining is that the state does not seem to get loaded when the application starts (as simple test app uploaded previously shows).

Jeremy
Re: Saving addon state [message #964173 is a reply to message #964139] Tue, 30 October 2012 06:08 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas Schindl
Messages: 5013
Registered: July 2009
Senior Member
So you say it is in the XMI which gets written to the disk (you find it
inside your runtime-workspace) but you don't get the data when it gets
loaded the next time?

Please shows the code once more.

Tom

Am 30.10.12 10:35, schrieb Jeremy Stone:
> Thanks Tom...
>
> Quote:
>> Why aren't you simply pushing the value to the persisted state once you
>> know it changed?
>
>
> Yes we could do that - although a lifecycle event to persist when the
> application closes works for us. (Framework support akin to
> @PersistState would have been nice.)
>
> Quote:
>> The annotation only makes sense on elements who come and go (like the
>> part is one) but not for things like an Addon who come and never go.
>
>
> We use an addon to provide state across multiple views. Since the MAddon
> interface has persisted state exposed this seemed a good fit. And the
> state does get persisted to workbench.xmi.
>
> However the issue remaining is that the state does not seem to get
> loaded when the application starts (as simple test app uploaded
> previously shows).
>
> Jeremy
Re: Saving addon state [message #964183 is a reply to message #964173] Tue, 30 October 2012 06:21 Go to previous messageGo to next message
Jeremy Stone is currently offline Jeremy Stone
Messages: 7
Registered: October 2012
Junior Member
Quote:
So you say it is in the XMI which gets written to the disk (you find it
inside your runtime-workspace) but you don't get the data when it gets
loaded the next time?


That's right.

Quote:
Please shows the code once more.


It's the code posted as an attachment to my message of last Wednesday.

The com.cyclone.e4.persist.extension.addons.PersistentAddon class just prints the loaded state in the injected MAddon.
Re: Saving addon state [message #964265 is a reply to message #964183] Tue, 30 October 2012 07:32 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas Schindl
Messages: 5013
Registered: July 2009
Senior Member
I'm sorry to say but the fragment story is completely broken because the
platform team decided to switch from delta restore to workbench.xmi restore!

The current code simply always completely replaces your model element
with the one loaded from the fragment wiping all changes store it the model.

This is a MAJOR bug introduced with 4.2.0 and completely destroys the
plugin story. The only workaround today is not to use fragments but
switch to processors where you search if the addon is already there and
only add it if not found.

What a bug, I'm baffeled and shocked.

Tom

Am 30.10.12 11:21, schrieb Jeremy Stone:
> Quote:
>> So you say it is in the XMI which gets written to the disk (you find it
>> inside your runtime-workspace) but you don't get the data when it gets
>> loaded the next time?
>
>
> That's right.
>
> Quote:
>> Please shows the code once more.
>
>
> It's the code posted as an attachment to my message of last Wednesday.
>
> The com.cyclone.e4.persist.extension.addons.PersistentAddon class just
> prints the loaded state in the injected MAddon.
Re: Saving addon state [message #964283 is a reply to message #964265] Tue, 30 October 2012 07:53 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas Schindl
Messages: 5013
Registered: July 2009
Senior Member
For those interested here's the bug
https://bugs.eclipse.org/bugs/show_bug.cgi?id=393132

Tom

Am 30.10.12 12:32, schrieb Tom Schindl:
> I'm sorry to say but the fragment story is completely broken because the
> platform team decided to switch from delta restore to workbench.xmi restore!
>
> The current code simply always completely replaces your model element
> with the one loaded from the fragment wiping all changes store it the model.
>
> This is a MAJOR bug introduced with 4.2.0 and completely destroys the
> plugin story. The only workaround today is not to use fragments but
> switch to processors where you search if the addon is already there and
> only add it if not found.
>
> What a bug, I'm baffeled and shocked.
>
> Tom
>
> Am 30.10.12 11:21, schrieb Jeremy Stone:
>> Quote:
>>> So you say it is in the XMI which gets written to the disk (you find it
>>> inside your runtime-workspace) but you don't get the data when it gets
>>> loaded the next time?
>>
>>
>> That's right.
>>
>> Quote:
>>> Please shows the code once more.
>>
>>
>> It's the code posted as an attachment to my message of last Wednesday.
>>
>> The com.cyclone.e4.persist.extension.addons.PersistentAddon class just
>> prints the loaded state in the injected MAddon.
>
Re: Saving addon state [message #964318 is a reply to message #964283] Tue, 30 October 2012 08:30 Go to previous messageGo to next message
Christoph Keimel is currently offline Christoph Keimel
Messages: 297
Registered: December 2010
Location: Germany
Senior Member
This is also related to this Bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=389663
Re: Saving addon state [message #964396 is a reply to message #964265] Tue, 30 October 2012 09:34 Go to previous message
Jeremy Stone is currently offline Jeremy Stone
Messages: 7
Registered: October 2012
Junior Member
Thanks, guys for looking into this. Sorry to have been the bringer of bad news.

FWIW: we have (for the time being) worked around the persistence (for the add-on case) by basically doing our own thing - i.e. by explicitly reading/writing our own file rather than using the workbench.xmi based persistence.
Previous Topic:Part toolbar refresh issue
Next Topic:Sample Project with one view bug
Goto Forum:
  


Current Time: Sat Apr 19 05:54:54 EDT 2014

Powered by FUDForum. Page generated in 0.04776 seconds