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: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
