"alesj" wrote : "alesj" wrote :
| | * Service --> MC
| What to do about tracking this "OSGi --> MC" injection?
| If we add this service to bundle's inUse, then there is no proper callback to
decrease inUse count.
| Which in the case of ServiceFactory (SF) means SF::ungetService might never be
| We can completely ignore bundle service count + serviceCache,
| but potentially some service unregister could invoke SF::ungetService,
| although we would still be using it in MC bean.
The service tracking needs moving into the MC as part of this integration.
The issue is what you track against.
As part of the OSGi stuff, I've made the DeploymentUnit part of the MDR's
deployment level metadata. You should extend this concept so that the
dependency project can look for a "ServiceTracker" in the MDR rather than
a DeploymentUnit. The deployers project would then add the ServiceTracker
attachment by the default to the deployment level metadata.
If there is no such data (e.g. for MC contexts created by the bootstrap)
then you should track against the "SystemBundle", i.e. a shared default
The OSGi stuff would then just delegate to those items for service tracking
instead of having to do it itself in the AbstractBundleState.
View the original post :
Reply to the post :