I agree this is the theory, but it (i.e., services blowing up when you
use them) is not something that can really be prevented. Services can go
away at any time, so you never know when you use one if it will blow up,
you have to treat them like remote references and assume they always
could blow up.
Further, just because the OSGi framework holds onto a
registration/reference/object does not give you any guarantees that you
can do anything graceful in a synchronous event. If the object is the
front-end to a bluetooth device and the devices was powered off or went
out of range, no amount of synchronicity by the framework is going to
stop the service object from blowing up when you touch it.
Of course, people like the warm and fuzzy feeling that the framework is
providing them some guarantees. :-)
-> richard
Todor Boev wrote:
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 "unregister()" returns there is room
for some final calls to your service as users get notified and shut down.
If the service events were asynchronous the users of the service would
potentially blow up with an exception while attempting to use it and
only than receive an "unregistered" event. So the whole point of the
event goes down the drain - you want to know it's going to go down
before it does so you can avoid crashing with exceptions right? At the
same time the caller of "unregister()" wants to know that when his
call returns the service is no longer used by no one and he can
proceed to release the resources of the service with no fear that
someone will call in and mess something up.
Put all of these considerations together and it seems to me only a
synchronous unregistration event will work. And since the
unregistration must be synchronous it will be evil to make the
registration asynchronous don't you think? :)
Cheers,
Todor
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
