Eclipse Community Forums: Eclipse 4 » Saving addon state

Search

Help

Login

Home » Eclipse Projects » Eclipse 4 » Saving addon state

Show: Today's Messages :: Show Polls :: Message Navigator

Switch to threaded view of this topic

Create a new topic

Submit Reply

Saving addon state [message #949936]

Fri, 19 October 2012 13:07

Jeremy Stone is currently offline

Friend

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?

Report message to a moderator

Re: Saving addon state [message #952033 is a reply to message #949936]

Sun, 21 October 2012 05:35

Lars Vogel is currently offline

Friend

Messages: 1098
Registered: July 2009

Senior Member

Looks like you using the getter in the place where you want to save. Wink

Wink

Report message to a moderator

Re: Saving addon state [message #952037 is a reply to message #949936]

Sun, 21 October 2012 05:37

Lars Vogel is currently offline

Friend

Messages: 1098
Registered: July 2009

Senior Member

Looks like you using the getter in the place where you want to save. Wink

Wink

Report message to a moderator

Re: Saving addon state [message #952049 is a reply to message #949936]

Sun, 21 October 2012 05:35

Lars Vogel is currently offline

Friend

Messages: 17
Registered: July 2009

Junior Member

Looks like you using the getter in the place where you want to save. ;)

Report message to a moderator

Re: Saving addon state [message #952050 is a reply to message #949936]

Sun, 21 October 2012 05:37

Lars Vogel is currently offline

Friend

Messages: 17
Registered: July 2009

Junior Member

Looks like you using the getter in the place where you want to save. ;)

Report message to a moderator

Re: Saving addon state [message #952056 is a reply to message #949936]

Sun, 21 October 2012 05:35

Lars Vogel is currently offline

Friend

Messages: 17
Registered: July 2009

Junior Member

Looks like you using the getter in the place where you want to save. ;)

Report message to a moderator

Re: Saving addon state [message #952057 is a reply to message #949936]

Sun, 21 October 2012 05:37

Lars Vogel is currently offline

Friend

Messages: 17
Registered: July 2009

Junior Member

Looks like you using the getter in the place where you want to save. ;)

Report message to a moderator

Re: Saving addon state [message #952062 is a reply to message #949936]

Sun, 21 October 2012 05:35

Lars Vogel is currently offline

Friend

Messages: 17
Registered: July 2009

Junior Member

Looks like you using the getter in the place where you want to save. ;)

Report message to a moderator

Re: Saving addon state [message #952063 is a reply to message #949936]

Sun, 21 October 2012 05:37

Lars Vogel is currently offline

Friend

Messages: 17
Registered: July 2009

Junior Member

Looks like you using the getter in the place where you want to save. ;)

Report message to a moderator

Re: Saving addon state [message #952069 is a reply to message #949936]

Sun, 21 October 2012 05:35

Lars Vogel is currently offline

Friend

Messages: 17
Registered: July 2009

Junior Member

Looks like you using the getter in the place where you want to save. ;)

Report message to a moderator

Re: Saving addon state [message #952070 is a reply to message #949936]

Sun, 21 October 2012 05:37

Lars Vogel is currently offline

Friend

Messages: 17
Registered: July 2009

Junior Member

Looks like you using the getter in the place where you want to save. ;)

Report message to a moderator

Re: Saving addon state [message #952273 is a reply to message #952050]

Sun, 21 October 2012 10:02

Lars Vogel is currently offline

Friend

Messages: 1098
Registered: July 2009

Senior Member

Sorry for posting the same thing x times, looks like my browser got crazy.

Report message to a moderator

Re: Saving addon state [message #953418 is a reply to message #952273]

Mon, 22 October 2012 08:24

Jeremy Stone is currently offline

Friend

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).

Report message to a moderator

Re: Saving addon state [message #956164 is a reply to message #949936]

Wed, 24 October 2012 09:37

Jeremy Stone is currently offline

Friend

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?

Attachment: e4_persist_test.zip
(Size: 37.34KB, Downloaded 239 times)

Report message to a moderator

Re: Saving addon state [message #956318 is a reply to message #956164]

Wed, 24 October 2012 12:08

Thomas Schindl is currently offline

Friend

Messages: 6651
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?
>

Report message to a moderator

Re: Saving addon state [message #956463 is a reply to message #956318]

Wed, 24 October 2012 14:30

Jeremy Stone is currently offline

Friend

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.)

Report message to a moderator

Re: Saving addon state [message #958836 is a reply to message #956463]

Fri, 26 October 2012 08:49

Thomas Schindl is currently offline

Friend

Messages: 6651
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.)

Report message to a moderator

Re: Saving addon state [message #964139 is a reply to message #949936]

Tue, 30 October 2012 09:35

Jeremy Stone is currently offline

Friend

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

Report message to a moderator

Re: Saving addon state [message #964173 is a reply to message #964139]

Tue, 30 October 2012 10:08

Thomas Schindl is currently offline

Friend

Messages: 6651
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

Report message to a moderator

Re: Saving addon state [message #964183 is a reply to message #964173]

Tue, 30 October 2012 10:21

Jeremy Stone is currently offline

Friend

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.

Report message to a moderator

Re: Saving addon state [message #964265 is a reply to message #964183]

Tue, 30 October 2012 11:32

Thomas Schindl is currently offline

Friend

Messages: 6651
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.

Report message to a moderator

Re: Saving addon state [message #964283 is a reply to message #964265]

Tue, 30 October 2012 11:53

Thomas Schindl is currently offline

Friend

Messages: 6651
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.
>

Report message to a moderator

Re: Saving addon state [message #964318 is a reply to message #964283]

Tue, 30 October 2012 12:30

Christoph Keimel is currently offline

Christoph Keimel

Friend

Messages: 482
Registered: December 2010
Location: Germany

Senior Member

This is also related to this Bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=389663

Report message to a moderator

Re: Saving addon state [message #964396 is a reply to message #964265]

Tue, 30 October 2012 13:34

Jeremy Stone is currently offline

Friend

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.

Report message to a moderator

Switch to threaded view of this topic

Create a new topic

Submit Reply

Previous Topic:	Part toolbar refresh issue
Next Topic:	Sample Project with one view bug

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Fri Apr 19 03:26:31 GMT 2024

Powered by FUDForum. Page generated in 0.03131 seconds

.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top