That's my understanding of how it should work as well. Obviously invoking
a proxy with no implementation would be a problem but the swap should
happen without pain.
On Tue, Feb 9, 2016 at 1:32 PM, Quinn Stevenson <qu...@pronoia-solutions.com
> wrote:
> In reference to the Blueprint proxy - if I use the Camel Bean component to
> call the service (i.e. to( “bean://my-bean” ), and I do NOT inject the
> service reference into the route builder, I get the dynamic swap of the
> service implementation. That (along with reading the Blueprint specs) lead
> to me to believe that the service proxy isn’t swapped - just the underlying
> service reference.
>
> > On Feb 9, 2016, at 10:32 AM, Brad Johnson <brad.john...@mediadriver.com>
> wrote:
> >
> > Richard, how much of a performance hit do you think it would be to do a
> > look up of the service via a tracker? Since I live in I/O bound
> > environments that sort of hit is usually acceptable as long as it isn't
> too
> > extreme. That's especially true if it brings better stability and
> dynamic
> > class handling. If I'm understanding the proposed mechanics this would
> > make the hot swapping and service references more stable. When
> > Camel/blueprint/OSGi proxy and interface to a concrete implementation
> and a
> > hot swap happens, does it create a new proxy or does it swap the
> > implementation that the proxy holds? The latter would be a preferred
> > mechanism I'd think. The bundle holding the reference to a proxied
> service
> > then doesn't ever lose the reference since it is just pointing to the
> > proxy. But the internal implementation might be set to a different class
> > e.g. switching from a test stub bundle to an implementation bundle.
> >
> > If we are going to change any of the classloader mechanics please put
> > guards around the classloaders in blueprint so that we can have a setting
> > to short circuit some of the slop bucket classloading that goes on there.
> > From the comments in the code it was put in place to accommodate JBI but
> it
> > has resulted in some unpredictable behavior when loading
> > classes/services. That should be relatively easy and painless to put in
> > place. I've put a Jira ticket in for that as well. But if there is
> going
> > to be some work on the blueprint/osgi classloaders now would be a good
> time
> > to address that as well. A simple boolean with a strict OSGi mode that,
> > when set to true, disallows SU classloader mechanics but would be false
> by
> > default.
> >
> > Does OSGi manage the other registries? In other words, when I fire up a
> > context and it creates a simple registry in Camel is that simple registry
> > managed by the OSGi registry? Should it be? I haven't wandered into that
> > section of code.
> >
> > On Tue, Feb 9, 2016 at 9:53 AM, Quinn Stevenson <
> qu...@pronoia-solutions.com
> >> wrote:
> >
> >> That sounds good to me - I rely pretty heavily on the
> >> ServiceUnavailableException after the proxy times-out, so I didn’t want
> >> this behavior to change (or at least I need to know if it’s going to
> >> change).
> >>
> >> Is looking-up the service in the OSGi Registry expensive? I thought the
> >> OSGi internals cached those services for us.
> >>
> >>
> >>> On Feb 9, 2016, at 8:15 AM, Richard Davidson <
> >> richard.davidson...@gmail.com> wrote:
> >>>
> >>> I am not sure what the order the registries are chained together. I
> need
> >> to
> >>> test whether the blueprint or the OSGI registry is first, From looking
> at
> >>> the code:
> >>> {code}
> >>>
> >>> public static Registry wrapRegistry(CamelContext camelContext,
> >> Registry
> >>> registry, BundleContext bundleContext) {
> >>>
> >>> ObjectHelper.notNull(bundleContext, "BundleContext");
> >>>
> >>> LOG.debug("Setting up OSGi ServiceRegistry");
> >>>
> >>> OsgiServiceRegistry osgiServiceRegistry = new
> OsgiServiceRegistry(
> >>> bundleContext);
> >>>
> >>> // Need to clean up the OSGi service when camel context is
> closed.
> >>>
> >>> camelContext.addLifecycleStrategy(osgiServiceRegistry);
> >>>
> >>> CompositeRegistry compositeRegistry = new CompositeRegistry();
> >>>
> >>> compositeRegistry.addRegistry(osgiServiceRegistry);
> >>>
> >>> compositeRegistry.addRegistry(registry);
> >>>
> >>> return compositeRegistry;
> >>>
> >>> }
> >>> {code}
> >>>
> >>> I think the OSGI registry would be first in the chain as it is first in
> >> the
> >>> composite registry. If this is true then the the OSGI registry would be
> >>> checked first, and if it didn't exist in the OSGI registry then it
> would
> >>> try blueprint. I think this is wrong and the OSGI registry should be
> >> added
> >>> to the end of the chain, so blueprint etc is tried first. However
> making
> >>> this change would change existing functionality and could cause issues
> >> for
> >>> existing deployments.
> >>>
> >>> Another point to note is that the service tracker change only works of
> >> the
> >>> processor looks up the registry every-time to get the service. If it
> >> holds
> >>> on to the service reference and the service goes away, requests will
> >> fail.
> >>>
> >>> In my view adding service trackers to OsgiServiceRegistry is an
> >> improvement
> >>> on what exists today, but I would still strongly advise using blueprint
> >>> proxies instead, as the reference to the service can be cached in the
> >>> processor.
> >>>
> >>>
> >>>
> >>>
> >>> On Tue, Feb 9, 2016 at 2:55 PM, Quinn Stevenson <
> >> qu...@pronoia-solutions.com
> >>>> wrote:
> >>>
> >>>> I normally use Blueprint to use OSGi Services. In that case, I should
> >>>> wind up with a Blueprint service proxy. Would using a ServiceTracker
> >> with
> >>>> a Blueprint proxy be necessary? I think the Blueprint proxy already
> >> does
> >>>> that for me.
> >>>>
> >>>>
> >>>>> On Feb 9, 2016, at 2:31 AM, Claus Ibsen <claus.ib...@gmail.com>
> wrote:
> >>>>>
> >>>>> On Tue, Feb 9, 2016 at 10:15 AM, Richard Davidson
> >>>>> <richard.davidson...@gmail.com <mailto:richard.davidson...@gmail.com
> >>
> >>>> wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> Instead of the cache containing the actual service objects it could
> it
> >>>>>> contain a org.osgi.util.tracker.ServiceTracker. This would then
> cache
> >>>> and
> >>>>>> track the service internally. Each time the service is requested via
> >> the
> >>>>>> registry, #ServiceTracker.getService() could be called. Let me know
> >>>> your
> >>>>>> thoughts, and if people agree I could try to create a patch.
> >>>>>>
> >>>>>
> >>>>> Yeah we use service tracker to track components and whatnot.
> >>>>>
> >>>>> I have said it many times, we love contributions
> >>>>> http://camel.apache.org/contributing <
> >>>> http://camel.apache.org/contributing>
> >>>>>
> >>>>>>
> >>>>>> On Tue, Feb 9, 2016 at 8:05 AM, Claus Ibsen <claus.ib...@gmail.com>
> >>>> wrote:
> >>>>>>
> >>>>>>> Hi
> >>>>>>>
> >>>>>>> Yeah it was created that way - i guess maybe the though was that
> osgi
> >>>>>>> reference lookup is expensive?
> >>>>>>>
> >>>>>>> I guess we can reach out to the OSGi folks and see what they say.
> It
> >>>>>>> would make the code simpler without a local cache.
> >>>>>>>
> >>>>>>>
> >>>>>>> On Tue, Feb 9, 2016 at 1:31 AM, Tim Jones <t...@mccarthy.co.nz>
> >> wrote:
> >>>>>>>> I have looked at the code in
> >>>>>>> org.apache.camel.core.osgi.OsgiServiceRegistry
> >>>>>>>> (camel-core-osgi-2.15.4) and it appears to cache the service
> >>>> references.
> >>>>>>>> This means that if I uninstall/install the bundle supplying the
> >>>> service
> >>>>>>> it
> >>>>>>>> wont automagically 'pick up' the new service.
> >>>>>>>>
> >>>>>>>> For what reason(s) are the service references cached?
> >>>>>>>>
> >>>>>>>> Note - after modifying OsgiServiceRegistry and removing the cache
> a
> >>>> new
> >>>>>>>> service is picked up and behaves more like I would expect in a
> >> dynamic
> >>>>>>> OSGi
> >>>>>>>> environment.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> View this message in context:
> >>>>>>>
> >>>>
> >>
> http://camel.465427.n5.nabble.com/OsgiServiceRegistry-caching-service-references-why-tp5777410.html
> >>>>>>>> Sent from the Camel - Users mailing list archive at Nabble.com.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Claus Ibsen
> >>>>>>> -----------------
> >>>>>>> http://davsclaus.com @davsclaus
> >>>>>>> Camel in Action 2: https://www.manning.com/ibsen2
> >>>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Claus Ibsen
> >>>>> -----------------
> >>>>> http://davsclaus.com <http://davsclaus.com/> @davsclaus
> >>>>> Camel in Action 2: https://www.manning.com/ibsen2 <
> >>>> https://www.manning.com/ibsen2>
> >>>>
> >>
> >>
>
>
