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

Reply via email to