On Fri, 1 Mar 2019 at 14:28, Michael Lipp <m...@mnl.de> wrote: > > Have you tried using a BundleTracker? > > It doesn't give you internal access to the Framework's locks... nothing > does I believe (and hope!). > > In a way, it does. BundleTracker.Tracked implements > SynchronousBundleListener. An instance of Tracked holds a lock on itself > during the processing of the relevant listener callbacks (most of which > hold a "state change" lock on the bundle). It thus "forwards" the internal > "state change" lock to a lock on itself. So all the operations of > BundleTracker that are synchronized on its associated instance of Tracked > are effectively synchronized on the framework's internal "state change" > lock. It's just a rather complicated way to access that "state change" lock. >
I've never cared that much about the internal implementation of BundleTracker. It just works... Neil > But thanks for the hint, I had forgotten about the bundle tracker---it's > not required very often. It seems like big tool for my simple problem. I'll > check if it does what I need. > > Michael > > > It does however handle the complexity of getting current state and > listening at the same time. When you open the tracker, the addingBundle() > method (which you should override) is invoked with any bundles that are > *already* in the state that you are looking for. Then addingBundle() is > invoked for any bundles that later enter the state you are looking for. In > any case it is only invoked once, unless of course a bundle transitions in > and out of the required state multiple times. This should solve your > non-idempotent problem. > > Neil > > On Fri, 1 Mar 2019 at 12:39, Michael Lipp via osgi-dev < > osgi-dev@mail.osgi.org> wrote: > >> Hi, >> >> I just want to make sure: there's no method for obtaining the "state >> change" lock on a Bundle, right? >> >> I'm asking because I want an action to be performed once the bundle has >> reached a particular state. Without this lock I have to follow the usual >> procedure for such cases: >> >> * Check for target state >> >> * Register listener >> >> * Check for target state again (because target state may have been >> reached between previous check and registration of listener, so listener >> is never invoked). >> >> ... which gets a bit more complicated still if the action to be >> performed when the target state is reached isn't idempotent. >> >> A bundle "state change" lock is mentioned in the >> SynchronousBundleListener API, but I couldn't find a way to access it. >> >> Best regards, >> >> Michael >> >> _______________________________________________ >> OSGi Developer Mail List >> osgi-dev@mail.osgi.org >> https://mail.osgi.org/mailman/listinfo/osgi-dev > > >
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
