We switched from BP to DS for that very reason. On Sep 13, 2013, at 12:19 PM, Neil Bartlett <[email protected]> wrote:
> 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 _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
