No - I haven’t tried logging the class type. I know it’s not a proxy because I don’t get a ServiceTimeoutException when the service is unavailable. I guess it could be a broken proxy, but I doubt it.
I’ll try a couple of things and post my results. > On Feb 18, 2016, at 3:24 PM, Brad Johnson <brad.john...@mediadriver.com> > wrote: > > When you run this below where you inject the blueprintServiceReference into > the routebuilder, have you tried do a > blueprintServiceReference.getClass().getName() log of print out? You > should see the com.sun.Proxy class and not a concrete class. That's when I > knew something was wrong for me. But I was using the package scanner. > What appears to be happening, though I do no know this for sure, is that > with that mechanic these are not getting pulled out of the Blueprint > registry as proxied objects but out of an OSGi registry as non-proxied > concrete objects but I'm not positive of it and I had to get code working > and couldn't continue to run it down. I switched designs instead. > > I ran into these problems when I was interacting with Java DSL > RouteBuilders and I've stopped using them. I don't seem to have the problem > as long as I stick with blueprint XML and pure Java Pojos. The only > exception I make to that is I'll use @Endpointinject to make a connector > class that lets me invoke my routes from Java. Since they are encapsulated > in a small class all the send/request mechanics and casting are tucked away > and Java code using it is just invoking methods on that connector. It > works. > > > But back to your sample, when you do a printlin on the property injection > of blueprintServiceReference what do you see? > > <reference id="echo-service" interface="com.pronoia.test.osgi.service.Echo" > filter="instance=one" timeout="2000" /> > > <bean id="very-simple-route-builder" class="com.pronoia.test.camel. > builder.VerySimpleBuilder"> > <property name="blueprintServiceReference" ref="echo-service" /> > </bean> > > <camelContext id="very-simple-context" xmlns=" > http://camel.apache.org/schema/blueprint"> > <routeBuilder ref="very-simple-route-builder" /> > </camelContext> > > On Thu, Feb 18, 2016 at 4:14 PM, Brad Johnson <brad.john...@mediadriver.com> > wrote: > >> Quinn, >> >> I don't recall if you answered this or not but when you run this: >> >> >> On Thu, Feb 18, 2016 at 9:18 AM, Quinn Stevenson < >> qu...@pronoia-solutions.com> wrote: >> >>> This one is really killing me. >>> >>> If anyone has any idea what may be going on and can point me in the right >>> direction, I’d love to take a shot at fixing it - I just don’t know where >>> to start looking. >>> >>> >>>> 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 >>>> >>> >>> >>