Richard S. Hall wrote: > > Yes. iPOJO is of the philosophy that service departures will likely lead > to errors, so you are better off being prepared to catch them and fail > gracefully, sort of like errors in distributed computing. Even if you > hold a dedicated lock, there is no guarantee that calling a method on > the service object won't throw an exception. Locks don't stop the > service from going away (think bluetooth device), in some cases if it > goes away it is gone, period. >
I completely agree. This is all about "crashing safely", not trying to avoid crashes with synchronization. Crashing safely means we always get an exception when trying to access a missing service. If we allow some final calls to an unregistered service object we risk getting random return values and other behavior that can corrupt the importing bundle. Here the question is if we should count on the exporter to place extra invalidation code in his service object so it consistently throws exceptions at late retainers? Or should we take matters in our own hands and guarantee a ServiceUnavailableException will always be thrown from our own internal tracking code? Todor --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
