Quinn,

If you wouldn't mind putting a reference in there as a "may be related to"
the other issue that would be great.  There shouldn't be a reason in an
OSGi environment for any classloaders grabbing concrete implementations
from other bundles and the current Camel classloader mechanics explicitly
use that reach around when they can't find what they are looking for. It
may be a different bug but ultimately that loophole has to be closed.

Brad

On Fri, Feb 5, 2016 at 3:01 PM, Quinn Stevenson <qu...@pronoia-solutions.com
> wrote:

> OK - I’ve created an new JIRA issue describing what I’m seeing.
> https://issues.apache.org/jira/browse/CAMEL-9570 <
> https://issues.apache.org/jira/browse/CAMEL-9570>
>
>  I’ll extract some samples from my projects and add them to the ticket
> shortly.
>
>
> > On Feb 3, 2016, at 12:05 AM, Christian Schneider <
> ch...@die-schneider.net> wrote:
> >
> > I would use a new issue that just explains what happens without trying to
> > interpret. We do not yet know what really happens but I hope we can find
> > out.
> >
> > Christian
> >
> > 2016-02-03 3:40 GMT+01:00 Quinn Stevenson <qu...@pronoia-solutions.com>:
> >
> >> I would expect the CamelContext to keep trying to run as well, but I
> >> expected it to hit the call to the OSGi service, block, and then timeout
> >> and throw a ServiceUnavailableException.  But what I’m seeing is the
> call
> >> to the OSGi service is completing (it’s basically and echo service right
> >> now), and continues to complete.  My test route is driven by a timer,
> and
> >> it will continue to log calls to the OSGi service even when the bundle
> >> providing the service has been stopped.
> >>
> >> I checked and made sure I didn’t have any other bundles providing the
> >> service.
> >>
> >> The really strange part to me is just injecting what should be the
> service
> >> proxy into the RouteBuilder results in a route that isn’t using
> Blueprint
> >> service proxies.  I’ve changed the route to use the bean component,
> which
> >> works as I’d expect as long as I don’t inject the bean into the route
> >> builder.
> >>
> >> I was going to put some samples in the JIRA issue that was created for
> >> this - is that still the right place?  Or do we need a different JIRA
> issue?
> >>
> >>> On Feb 2, 2016, at 3:15 PM, Christian Schneider <
> ch...@die-schneider.net>
> >> wrote:
> >>>
> >>> On 02.02.2016 23:08, Quinn Stevenson wrote:
> >>>> Christian -
> >>>>
> >>>> I don’t know about a class loader issue, but I do know when I run the
> >> route configured as you have it below, I’m not getting a proxy to the
> >> service.  I know this because if I stop the bundle containing the OSGi
> >> service, the Camel context keeps running - I don’t get a
> >> ServiceUnavailableException after the timeout.  In fact, it keeps using
> >> whatever is injected into the RouteBuilder.
> >>>>
> >>>> I think that’s where the class loader thing came from - it appear to
> be
> >> using the implementation of the service directly - not via a Blueprint
> >> proxy.
> >>>>
> >>>>
> >>> It is normal that the camel context keeps running as blueprint uses
> >> service damping. So the proxy should remain the same when the service
> goes
> >> away or changes.
> >>> I would expect the service call to block and return
> >> ServiceUnavailableException after the blueprint service timeout though
> in
> >> case there is no service.
> >>>
> >>> Sounds quite strange.
> >>>
> >>> Can you check in karaf using the service:list command that there is
> >> really no Echo service running anymore?
> >>>
> >>> Christian
> >>>
> >>> --
> >>> Christian Schneider
> >>> http://www.liquid-reality.de
> >>>
> >>> Open Source Architect
> >>> http://www.talend.com
> >>>
> >>
> >>
> >
> >
> > --
> > --
> > Christian Schneider
> > http://www.liquid-reality.de
> > <
> https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de
> >
> >
> > Open Source Architect
> > http://www.talend.com
> > <
> https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com
> >
>
>

Reply via email to