Christian, I consider that to be one of the worst features of Blueprint, so I would be very opposed to adding it to DS!
Regards Neil On Fri, Sep 13, 2013 at 11:17 AM, Christian Schneider <[email protected]> wrote: > I think you can take a look at what aries blueprint does for these cases. > They create a proxy for each injected service and switch the service if the > original one goes away. If no service is available then I think it > waits for some time for a new one to come and throws an exception if a time > out happens. > > Perhaps a similar behaviour can also be added for DS. Not sure if it matches > the DS ideas though. > > Christian > > > On 13.09.2013 12:10, Thomas Diesler wrote: > > Thank you all for your replies. We ended up with three measures > > #1 assert that the component is still valid on entry of every public method > (AtomicBoolean set by activate/deactivate) > #2 Use a ValidatingReference to hold unary references to dependent services > (prevents NPE when a dependent service goes away) > #3 Throw an InvalidComponentException runtime exception on #1 and #2 > > The idea is that access to a deactivated reference never throws NPE > Access to the public API is prevented from deactivated service instances > > cheers > --thomas > > On Sep 11, 2013, at 11:11 AM, Richard S. Hall <[email protected]> wrote: > > Resending my reply from yesterday since my original message didn't seem to > go through... > > ---- > > Yes, you can do some of these sorts of things with iPOJO. > > First, iPOJO has the notion of a service-level service dependency as well as > an implementation-level service dependency (which is the level of DS > dependencies). Second, iPOJO caches services references within a service > method invocation so that a thread calling a method on a service will see > the same injected services until the thread exits the invoked service > method. > > It doesn't deal with configuration locking (at least not of which I am > aware). > > -> richard > > On 9/10/13 06:41 , Thomas Diesler wrote: > > Hi Folks, > > in Fabric we have a service model whereby services have interdependencies, > are configurable and dynamic by nature - all of which is managed in OSGi > with the help of Declarative Services. To illustrate I use a simple example > > ServiceT { > > @Reference > ServiceA serviceA; > > @Reference > ServiceB serviceB; > > public doStuff() { > // that uses serviceA & serviceB > } > } > > > The injection is handled by the DS framework - there are various callbacks > involved. > > Lets assume the system is fully configured and a client makes a call on > ServiceT > > ServiceT serviceT = getServiceT(); > serviceT.doStuff(); > > > Due to the dynamic nature of OSGi services and their respective > configuration ServiceT must deal with the following possible/likely > situations > > #1 An instance of a referenced service is not available at the point of > access (i.e. serviceA is null) > #2 In the context of a single call the service instance may change (i.e. > call may span multiple instances of serviceA) > #3 In the context of a single call the configuration of a service instance > may change (i.e. serviceA is not immutable, sequential operations on A may > access different configurations) > > In OSGi there is no notion of global lock for service/configurations nor a > notion of lock of a given set of services/configurations - I cannot do > > lock(T, A, B); > try { > ServiceT serviceT = getServiceT(); > serviceT.doStuff(); > } finally { > unlock(T, A, B); > } > > This code is also flawed because it assumes that the caller of doStuff() is > aware of the transitive set of services involved in the call and that this > set will not change. > > As a conclusion we can say that the behaviour of doStuff() is only defined > when we assume stability in service availability and their respective > configuration, which happens to be true most of the time - nevertheless, > there are no guarantees for defined behaviour. > > How about this … > > The functionality of A and B and its respective configuration is decoupled > from OSGi and its dynamicity > > > A { > final Map config; > public doStuffInA() { > } > } > > B { > final Map config; > public doStuffInB() { > } > } > > > ServiceA and ServiceB are providers of immutable instances of A and B > respectively. There is a notion of CallContext that provides an idempotent > set of instances involved in the call. > > CallContext { > public T get(Class<T> type); > } > > This guarantees that throughout the duration of a call we always access the > same instance, which itself is immutable. CallContext also takes care of > instance availability and may have appropriate timeouts if a given instance > type cannot be provided. It would still be the responsibility of A/B to > decide wether an operation is permissible on stale configuration. > > Changes to the system would be non-trival and before I do any prototyping > I'd like to hear what you think. > > cheers > --thomas > > > > _______________________________________________ > 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 > > > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com > > > _______________________________________________ > 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
