aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Grzybek <gr.grzy...@gmail.com>
Subject Re: A way to not wait on Blueprint <reference>
Date Tue, 26 Sep 2017 13:40:13 GMT
2017-09-26 15:31 GMT+02:00 Guillaume Nodet <gnodet@apache.org>:

> This can be implemented using reference listeners already and that's a good
> workaround imho.
>

you mean ordinary org.osgi.framework.ServiceListener?

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,
> ...)
>

Sure - I rather wanted it for opposite scenario. Not "if
(serviceproxy.available) { serviceproxy.call }", but rather "if (not
serviceproxy.available) { // skip call }" - so harmless false negative
instead of dangerous false positive.


> We could also add
>    DependencyHelper.isAvailable(myDependency)
> It may be easier to implement than having to add a custom interface to each
> proxy.
>

Currently Camel just calls
org.osgi.service.blueprint.container.BlueprintContainer#getComponentInstance()
in org.apache.camel.blueprint.BlueprintContainerRegistry#lookupByName().
It's totally unaware of ServiceReference, BundleContext etc...
If the returned proxy (when camel context is in one BP container and a
#service reference in another) could tell Camel if the service is available
or not, CAMEL-11810 could be fixed.

Of course I'm aware that this can't be automatic, as default <reference>
behavior should be "wait until ready or timeout", not "try wait"...


> 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.
>

In case of camel it's also directly tied to e.g.,
AbstractPropertyPlaceholder from aries blueprint...

regards
Grzegorz


>
> 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