Repository navigation
Support dynamic classloader-hook registration by framework extensions - #1367
Conversation
0c66d96 to
ea66118
Compare
tjwatson
left a comment
There was a problem hiding this comment.
I pushed a change to use ActivatorHookFactory to manage the tracker instance instead.
|
One subtle thing I changed in my commit is to not restrict the registrations to only when the framework is STARTING. I believe you will want that for the spi implementation when it is installed and resolved by p2. When a framework extension is resolved after framework start then it will dynamically call the extensions bundle activator. |
9282a83 to
6b8b425
Compare
|
Thank you Tom for the update. The
OK, that's fine for me as well. I assumed that P2 would require a framework restart anyway. But at the same time I'm not sure there are no cases where it's not happening later. I squashed your commit into the first one and made a few more adjustments, mainly in the With that, this is ready from my POV. |
6b8b425 to
00f5de4
Compare
00f5de4 to
f727a4c
Compare
Being able to register classloader-hooks dynamically in the extension activator avoids the need to add the extension to the boot-classpath via the 'osgi.framework.extensions' system property. Immediately use it in equinox.spi. Co-authored-by: Thomas Watson <tjwatson@us.ibm.com>
f727a4c to
78c5916
Compare
|
Just noticed that the Thanks again for your review and help. |
As discussed in
being able to register classloader-hooks dynamically in the extension activator avoids the need to add the extension to the boot-classpath via the
osgi.framework.extensionssystem-property.Immediately use it in equinox.spi.