Handle RESOLVED events in ServiceLoaderMediatorHook.modifiedBundle

[HannesWell]

A ServiceTracker that tracks bundles in state Bundle.RESOLVED | Bundle.STARTING | Bundle.ACTIVE | Bundle.STOPPING receives calls to modifiedBundle() where the event is RESOLVED again, if the wiring is updated, e.g. because new bundles were resolved.

@laeubi or @tjwatson is that assumption correct or are there other cases, that might be relevant here?

[github-actions]

Test Results

  234 files  ±0    234 suites  ±0   49m 28s ⏱️ -47s
2 231 tests ±0  2 182 ✅ ±0   49 💤 ±0  0 ❌ ±0 
6 456 runs  ±0  6 343 ✅ ±0  113 💤 ±0  0 ❌ ±0 

Results for commit 0be6617. ± Comparison against base commit d579f72.

[laeubi]

@HannesWell sadly the javadoc is surprisingly uninformative here https://docs.osgi.org/javadoc/osgi.core/8.0.0/org/osgi/framework/BundleEvent.html#RESOLVED the state diagram is what I most often look at for more information

I would say it depends a bit on the code / behavior if one can say it is really "irrelevant" I would at least clear all cached content for that bundle (if there is any) so everything is fetched fresh as it gets a new classloader in such case.

[HannesWell]

The javaDoc is indeed not very clear on that, unfortunately.

I would say it depends a bit on the code / behavior if one can say it is really "irrelevant" I would at least clear all cached content for that bundle (if there is any) so everything is fetched fresh as it gets a new classloader in such case.

Only information about the content of the bundle itself is cached. The wiring is read 'freshly' whenever considered.
And as far as I understand the doc, in case of a content update, which doesn't make the bundle to become unresolved (which would lead to a plain removal), we receive an UPDATED event:

• https://docs.osgi.org/specification/osgi.core/8.0.0/framework.lifecycle.html#i3032481

It seems to me that we only receive an RESOLVED event if the wiring changes and that doesn't require a refresh of cached data.

Since this is a fix for an existing issue, I'm submitting this now. If my assumption later to turn out to be wrong, we can still improve it.
Thanks for your review.

[laeubi]

It seems to me that we only receive an RESOLVED event if the wiring changes and that doesn't require a refresh of cached data.

If another bundle is updated (or new ones installed) or even uninstalled the wiring remains unless you force a refresh, so it should not have an influence of the content of the bundle itself, on the other hand it show in the diagram that an update of an bundle can lead to resolve again(not sure if this then gets an event...) what would e.g. possibly make the bundle change contained resources and classes.

[tjwatson]

It seems to me that we only receive an RESOLVED event if the wiring changes and that doesn't require a refresh of cached data.

This is the state mask you use:

	private static final int SERVICES_ACTIVE_STATES = Bundle.RESOLVED | Bundle.STARTING | Bundle.ACTIVE
			| Bundle.STOPPING;

I am surprised you are seeing the RESOLVED event in modifiedBundle given that event should only get fired when a bundle is transitioning from INSTALLED -> RESOLVED. That transition should should cause the addingBundle method to get called, not the modifiedBundle method. When the bundle transitions from RESOLVED -> INSTALLED then the removedBundle method should be called. I would never expect the modifiedBundle to be called for the RESOLVED.

Note that when the tracker is opened all bundle states that match the state mask will be passed to addingBundle, none will be passed to modifiedBundle. So that logic needs to handle when a bundle is already in the STARTING, ACTIVE or STOPPING state for providing/using services.

What I've usually done is had addingBundle simply call modifiedBundle and then write the logic in there to not care about the event at all, instead just act upon the current state of the bundle and what you want to do when the bundle is in the STARTING, ACTIVE or STOPPING state. Then have removedBundle do the necessary cleanup.

[tjwatson]

BTW this is the diagram you want to refer to for bundle states. The one referred to earlier was for the framework states, which will confuse you.