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 14:07:05 GMT
2017-09-26 15:40 GMT+02:00 Grzegorz Grzybek <gr.grzybek@gmail.com>:

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

No, a blueprint reference listener:

<reference id="ref2"
interface="org.apache.aries.blueprint.sample.InterfaceA" timeout="100">
<reference-listener bind-method="bind" unbind-method="unbind"
ref="bindingListener" />
</reference>



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



-- 
------------------------
Guillaume Nodet

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