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