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>
