This can be implemented using reference listeners already and that's a good workaround imho. That said, I'm certainly not opposed to adding a way to check the presence of the service (though it can't really be safe, as there's no way to synchronize the check and the later call), unless both are done using reflection using something like: DependencyHelper.callIfAvailable(myDependency, "mymethod", arg1, arg2, ...) We could also add DependencyHelper.isAvailable(myDependency) It may be easier to implement than having to add a custom interface to each proxy.
But again, I'm not sure it's really easier or better than adding the bind/unbind methods instead of injecting the proxy directly. The downside of this new approach is a tighter coupling (and outside the spec) to Aries Blueprint. 2017-09-26 15:21 GMT+02:00 Grzegorz Grzybek <[email protected]>: > Hello > > I'm working on: > - https://issues.apache.org/jira/browse/CAMEL-11810: Lifecycle problems > for services retrieved from Blueprint container > - https://issues.apache.org/jira/browse/ARIES-1174: service reference > timeout when system bundle is stopping > > Actually I think the problem is as old as blueprint specification itself... > <reference> returns Aries (or JDK) proxies that delegate to Callables which > return target objects. > > Even specification is clear here - target services is obtained OR > org.osgi.service.blueprint.container.ServiceUnavailableException is > thrown. > > We all got used to this behavior and it's clear that it's not easy to > decide when we *don't need* to wait for a service which is not going to be > available (like during framework shutdown). > > I'm thinking about additional interface that proxies (jdk and asm) could > implement, so we could explicitly check whether target service is available > *without wait*. One such case could be Camel context being stopped - > possibly after telling it *not to* wait for services (in case of > BlueprintCamelContext implementation). > > I know it's "in specification", but having "AriesProxy.tryGetService()" > method could be useful as "implementation specific" feature... What do you > think? > > regards > Grzegorz Grzybek > -- ------------------------ Guillaume Nodet
