Thanks Chris, could you say something about the effect on call stacks that are already in progress. In a complex graph of interdependent services you may have multiple DS injection points and that a ref is null is only the most obvious case. What about the ref not being null but being a different instance than has been used earlier in the call stack. Also the possibility of different configuration data getting associated with the same service instance.
cheers --thomas On Sep 10, 2013, at 4:39 PM, [email protected] wrote: >> I'm wondering how other folks deal with the issues of service >> dynamicity and configuration change in the duration of a single call to a >> complex graph of interconnected services. > > Services injected by DS are, as you say, non-final fields so they can > change their value. This situation is not unique to DS - in principle > *any* non-final field of your class could be modified at any time by any > other thread which can access it, so you have to either handle this or > prove that it can't happen. For example you make a copy in a (final) > local variable: then you are safe from NPEs but you may be using an > instance which is somehow obsolete - so you have to be aware of that. > Etc.. > > Turning to DS, the solution can depend upon whether the absence of a > dependency is a "normal" or an "abnormal" state of affairs. If it is > normal then you declare the dependency as "optional unary" and indeed you > have be aware that it can go away or be replaced at the most inconvenient > moment. As you say there are "a lot of callbacks": in this case you > almost certainly want to write your own set/unset methods so that you can > deal with synchronisation issues etc.. If OTOH you really don't want to > deal with the dynamics then you declare the dependency as "mandatory > unary" and then if it goes away, so do you. If it comes back a new > instance of your component is created so there is no problem of stale > references etc.. > > It is important that components properly handle being stopped: any > subsequent service calls should be handled in a way which helps the caller > realise that the service object is no longer usable. > > I don't think this is a problem which can be solved by adding one more > layer of abstraction; rather it is a case of applying best practices and > using DS idiomatically. Does this make sense? > > Regards > > Chris Gray > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
