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