The BundleTracker uses SynchronousBundleListener to be able to see all the BundleEvent types including RESOLVED. So your use of the BundleTracker must follow the advice for users of SynchronousBundleListener. See the doc for SynchronousBundleListener.
Since SynchronousBundleListener are synchronously called by the framework, it is important that SynchronousBundleListeners do not take a long time to return or attempt to manipulate the life cycle of the bundle whose BundleEvent is being delivered. This basically means that your BundleTracker should queue any long running work for another thread when an event occurs.
In that case, you have all the usual race condition concerns. When doing the processing asynchronously to the synchronous event delivery, the bundle, since it is now RESOLVED, can be called by other bundles and can proceed in its lifecycle to be activated.
Anything you do synchronous to the event in the tracker will happen-before the bundle's life cycle can proceed since the SynchronousBundleListener must first return to allow that to happen.
So there is a tension between getting the work done synchronously to the event and doing too much work synchronous to the event. You will need to figure out the best tradeoff for you needs.
--
BJ Hargrave
Senior Technical Staff Member, IBM // office: +1 386 848 1781
OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
hargr...@us.ibm.com
BJ Hargrave
Senior Technical Staff Member, IBM // office: +1 386 848 1781
OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
hargr...@us.ibm.com
----- Original message -----
From: Mark Raynsford <list+org.o...@io7m.com>
Sent by: osgi-dev-boun...@mail.osgi.org
To: osgi-dev@mail.osgi.org
Cc:
Subject: [osgi-dev] Racing the BundleTracker
Date: Wed, May 31, 2017 5:44 PM
Hello.
So I now have what appears to be a working implementation of resource
registration and resolution via the Extender pattern.
Basically: A resource resolver service watches bundles with a
BundleTracker as they reach the RESOLVED state. It examines each bundle
and if that bundle has metadata that allows it to participate in
resource handling, the resources and packages exported by the bundle
are recorded.
The service itself is trivial:
https://github.com/io7m/callisto/blob/feature/interfaces-sketch-00/com.io7m.callisto.resources.main/src/main/java/com/io7m/callisto/resources/main/CoResourceResolver.java
The service inserts bundles into a resource model, and removes bundles
from the model when they're uninstalled. The bulk of the code of the
model implements scanning of bundle headers and wires, and implementing
the logic to traverse wires to look up resources:
https://github.com/io7m/callisto/blob/feature/interfaces-sketch-00/com.io7m.callisto.resources.main/src/main/java/com/io7m/callisto/resources/main/CoResourceModel.java
As I've said, this all appears to work properly. I have quite extensive
unit tests that cover close to 100% of the code, and the semantics seem
to be sane.
The problem: I don't know if there are race conditions.
If I install a bundle B that contains both resources and code, the
BundleTracker will register those resources when the bundle reaches the
RESOLVED state. I can (I think) assume that code in B (such as bundle
activators or immediate declarative services) will only execute when
the bundle reaches the ACTIVE state, and therefore I believe that I can
assume that the bundle tracker resource registration code for the
bundle will happen before (in the concurrent happens-before sense) the
activator or services start executing.
However, if some bundle C makes calls into code in B, and B tries to
resolve one of its own resources... Do I have any guarantees that the
resource resolution code in the BundleTracker will have completed
before code in bundle B has any opportunity to call the resolver
service? I feel like I don't have that guarantee... Is there any way to
get it?
M
attit24d.dat
Type: application/pgp-signature
Name: attit24d.dat_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
attilyud.dat
Description: Binary data
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
