Bundle self-update not delayed until refresh

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Bundle self-update not delayed until refresh

Todor Boev
I have a development tool bundle that updates a running equinox framework in batch mode.
I.e. it updates a list of bundles via Bundle.update() and then calls "FrameworkWiring.refresh()" on the entire batch. Sometimes the list includes the updater bundle itself.

In this case the thread that performs the updates needs to complete it's job - including the self update and then as the last act of the dead revision issue a refresh. In that case I expected that the bundle update will succeed with no noticeable effects. Later during the refresh the updater will be rebooted as normal. 

Instead however the updater is rebooted within the thread that performs Bundle.update(), and subsequently as the updater thread proceeds I hit a ClassNotFoundError since the old class loader is already destroyed and the old bundle revision jar is removed. I.e. the root cause of the error is a FileNotFoundException for the bundle revision to which the ModuleClassLoader of the old revision is bound.

I have also noticed such "eager update" mode in other cases that do not involve self update. So I though this is a nice occasion to ask when this happens and should it happen at all.

_______________________________________________
equinox-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev
Reply | Threaded
Open this post in threaded view
|

Re: Bundle self-update not delayed until refresh

Thomas Watson
I'm not sure I understand the scenario.

What I do know is that in the latest Equinox (since the Luna release) the framework will eagerly flush updated or uninstalled class loaders if they are not 'reachable' by any other in-use bundle in the framework.  It sounds to me like this may be what is effecting you in your scenario.  But in my opinion this is acceptable behavior because once a bundle is stopped it should no longer be doing any work on any thread.  It should not be trying to load additional classes any longer or doing work at all because it has stopped.  Now if the updated or uninstalled bundle exported some packages that are still in-use by other bundles in the system then the class loader for the bundle must remain functional until all in-use bundles of the exported package are refreshed also.

Tom





From:        Todor Boev <[hidden email]>
To:        Equinox development mailing list <[hidden email]>
Date:        12/20/2016 03:40 AM
Subject:        [equinox-dev] Bundle self-update not delayed until refresh
Sent by:        [hidden email]




I have a development tool bundle that updates a running equinox framework in batch mode.
I.e. it updates a list of bundles via Bundle.update() and then calls "FrameworkWiring.refresh()" on the entire batch. Sometimes the list includes the updater bundle itself.

In this case the thread that performs the updates needs to complete it's job - including the self update and then as the last act of the dead revision issue a refresh. In that case I expected that the bundle update will succeed with no noticeable effects. Later during the refresh the updater will be rebooted as normal. 

Instead however the updater is rebooted within the thread that performs Bundle.update(), and subsequently as the updater thread proceeds I hit a ClassNotFoundError since the old class loader is already destroyed and the old bundle revision jar is removed. I.e. the root cause of the error is a FileNotFoundException for the bundle revision to which the ModuleClassLoader of the old revision is bound.

I have also noticed such "eager update" mode in other cases that do not involve self update. So I though this is a nice occasion to ask when this happens and should it happen at all._______________________________________________
equinox-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev



_______________________________________________
equinox-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev