> 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
