Well, as promised, I finally got around to creating an example of using
BND as a testing harness for the Felix framework and for bundles. Some
simple documentation is here:
http://felix.apache.org/site/bnd-testing-harness.html
This is not a tutorial, just an example of how to use it (or at
Hi
I just found a deadlock in our code that was the result of the lack of
asynchronicity. When a service is registered in felix, the trackers are
notified in the same thread. Is
it the intended behavior ?
Looks to me that could lead to a very deep stack of invocation, no ? Of
course I can fix this
Yes, notifications to ServiceListeners (and therefore ServiceTrackers)
should occur synchronously in the thread that caused the
registration/unregistration of the service. Because of this it is
generally unwise to hold any locks when registering or unregistering a
service.
In many cases you
ServiceEvents are defined in the spec as being delivered on the calling
thread (i.e., synchronously). I agree, this sucks and shouldn't be that
way, but the spec says so.
- richard
Jacques-Olivier Goussard wrote:
Hi
I just found a deadlock in our code that was the result of the lack of
Kirk Knoernschild wrote:
Hey Richard,
This looks pretty cool. So do you know if BND actually starts the OSGi
framework and validates the bundles by starting them? Am I
understanding that correctly?
Each project (i.e., org.apache.felix.framework.test and
org.apache.felix.log) creates a
The synchronous event delivery is an attempt to make service
unregistration more graceful. This is the only way to provide an
'unregistering' event as opposed to 'unregistered'. E.g. when you
receive the event the service is still up and you can gracefully stop
using it. So before the call to
6 matches
Mail list logo
