aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@apache.org>
Subject Re: A way to not wait on Blueprint <reference>
Date Tue, 26 Sep 2017 13:31:05 GMT
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 <gr.grzybek@gmail.com>:

> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message