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