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