| Cleaning up controller instances attached to MParts in an E4 application [message #1268503] |
Mon, 10 March 2014 11:40  |
Eclipse User |
|
|
|
Hi,
when I build an E4 application with multiple MParts in the application model, I can rely on Eclipse's DI mechanism to create and destroy the contribution objects associated with these MParts. This means that, if I a put an event handling method like this:
@Inject
@Optional
void handleEvent(@UIEventTopic("MyTopic") Event event) {
// handle event here
}
into the contribution class of an MPart, the method will not be called to handle "MyTopic" events after the MPart is removed from the application model.
But I have noticed that this clean-up does not work for an event handling method in the controller class of a JavaFX view that is attached as a child to the root pane of the contribution class of an MPart, like this:
@PostConstruct
public void init(BorderPane pane, @FXMLLoader FXMLLoaderFactory loaderFactory) {
final FXMLBuilder<Node> builder = loaderFactory.loadRequestorRelative("View.fxml");
try {
final Node node = builder.load();
pane.setCenter(node);
} catch (IOException e) {
//
}
}
When the MPart is removed from the application model and a "MyTopic" event is sent, the controller's handleEvent method will be called, whereas the same method in the contribution object will not. At this point, the JavaFX view could have been removed from memory and destroyed, along with its controller, as their MPart container does not exist anymore.
Is this something e(fx)clipse should take care of? Or do I need to take care of it myself? Are there any best practices for this type of memory clean-up?
Thanks,
Uwe
|
|
|
| Re: Cleaning up controller instances attached to MParts in an E4 application [message #1268612 is a reply to message #1268503] |
Mon, 10 March 2014 14:47  |
| Eclipse User |
|
|
|
There should be nothing for you to clean up.
I'm currently at loss why the control is not detached because the
containing context should have been disposed so I need to track this
down in my sample app.
Tom
On 10.03.14 16:40, Uwe San wrote:
> Hi,
>
> when I build an E4 application with multiple MParts in the application
> model, I can rely on Eclipse's DI mechanism to create and destroy the
> contribution objects associated with these MParts. This means that, if I
> a put an event handling method like this:
>
>
> @Inject
> @Optional
> void handleEvent(@UIEventTopic("MyTopic") Event event) {
> // handle event here
> }
>
>
> into the contribution class of an MPart, the method will not be called
> to handle "MyTopic" events after the MPart is removed from the
> application model.
>
> But I have noticed that this clean-up does not work for an event
> handling method in the controller class of a JavaFX view that is
> attached as a child to the root pane of the contribution class of an
> MPart, like this:
>
>
> @PostConstruct
> public void init(BorderPane pane, @FXMLLoader FXMLLoaderFactory
> loaderFactory) {
> final FXMLBuilder<Node> builder =
> loaderFactory.loadRequestorRelative("View.fxml");
> try {
> final Node node = builder.load();
> pane.setCenter(node);
> } catch (IOException e) {
> // }
> }
>
>
> When the MPart is removed from the application model and a "MyTopic"
> event is sent, the controller's handleEvent method will be called,
> whereas the same method in the contribution object will not. At this
> point, the JavaFX view could have been removed from memory and
> destroyed, along with its controller, as their MPart container does not
> exist anymore.
>
> Is this something e(fx)clipse should take care of? Or do I need to take
> care of it myself? Are there any best practices for this type of memory
> clean-up?
>
> Thanks,
> Uwe
|
|
|
| Re: Cleaning up controller instances attached to MParts in an E4 application [message #1268636 is a reply to message #1268612] |
Mon, 10 March 2014 15:32 |
| Eclipse User |
|
|
|
Hi,
There's a general problem with event unsubscription I can even get
events for parts although the context is disposed.
I can remember having a discussion with Oleg 2 years ago because the
unsubscribing relies on the GC which is not reliable.
I filed an upstream bug [1] so that this gets fixed in the e4 project -
you can force the clean up by doing a System.gc() which really can't be
the correct solution.
Tom
[1]https://bugs.eclipse.org/bugs/show_bug.cgi?id=430041
On 10.03.14 19:47, Tom Schindl wrote:
> There should be nothing for you to clean up.
>
> I'm currently at loss why the control is not detached because the
> containing context should have been disposed so I need to track this
> down in my sample app.
>
> Tom
>
> On 10.03.14 16:40, Uwe San wrote:
>> Hi,
>>
>> when I build an E4 application with multiple MParts in the application
>> model, I can rely on Eclipse's DI mechanism to create and destroy the
>> contribution objects associated with these MParts. This means that, if I
>> a put an event handling method like this:
>>
>>
>> @Inject
>> @Optional
>> void handleEvent(@UIEventTopic("MyTopic") Event event) {
>> // handle event here
>> }
>>
>>
>> into the contribution class of an MPart, the method will not be called
>> to handle "MyTopic" events after the MPart is removed from the
>> application model.
>>
>> But I have noticed that this clean-up does not work for an event
>> handling method in the controller class of a JavaFX view that is
>> attached as a child to the root pane of the contribution class of an
>> MPart, like this:
>>
>>
>> @PostConstruct
>> public void init(BorderPane pane, @FXMLLoader FXMLLoaderFactory
>> loaderFactory) {
>> final FXMLBuilder<Node> builder =
>> loaderFactory.loadRequestorRelative("View.fxml");
>> try {
>> final Node node = builder.load();
>> pane.setCenter(node);
>> } catch (IOException e) {
>> // }
>> }
>>
>>
>> When the MPart is removed from the application model and a "MyTopic"
>> event is sent, the controller's handleEvent method will be called,
>> whereas the same method in the contribution object will not. At this
>> point, the JavaFX view could have been removed from memory and
>> destroyed, along with its controller, as their MPart container does not
>> exist anymore.
>>
>> Is this something e(fx)clipse should take care of? Or do I need to take
>> care of it myself? Are there any best practices for this type of memory
>> clean-up?
>>
>> Thanks,
>> Uwe
>
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03392 seconds
Home