You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Quinn Stevenson <qu...@pronoia-solutions.com> on 2016/01/26 23:11:24 UTC
Invoking Dynamic OSGi Blueprint services from a Java RouteBuilder
When I use an OSGi Service registered using Blueprint from a Java route (built using a Java RouteBuilder), the Camel route isn’t detecting the when the service is not available, and it isn’t updating when the service implementation changes.
The simple setup I’m using has a Java interface for the OSGi service in one bundle, and implementation of that interface which uses Blueprint to register the service in another bundle, and simple RouteBuilder that uses the service in a third bundle. The implementation of the service is injected into the RouteBuilder using Blueprint, and the Camel context is configured in Blueprint in a fourth bundle.
After all these bundles are installed and started in Karaf, the run and the hashCode of service is logged every time the Camel timer fires and triggers an exchange. If I stop the bundle that registers the service using Blueprint, the route continues to log the same hashCode when it calls the OSGi service. I would expect a ServiceUnavailableException after a timeout.
Additionally, when I restart the bundle that registers the service object, I continue to get the same hashCode. I would expect to get a new hashCode value.
Am I doing something wrong? Do I need to do something different do get the dynamic behavior I’m looking for?
The code looks like this:
Java Interface (service-interface bundle):
public interface Echo {
String execute(String body);
}
Java Implementation:
public class EchoServiceOne implements Echo {
Logger log = LoggerFactory.getLogger(this.getClass());
@Override
public String execute(String body) {
log.info( "{}:{} -> execute", this.getClass().getSimpleName(), this.hashCode() );
return body;
}
}
Blueprint Registering the service (service-one bundle):
<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0 http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd">
<service interface="com.pronoia.test.osgi.service.Echo" >
<service-properties>
<entry key="instance" value="one" />
</service-properties>
<bean class="com.pronoia.test.osgi.service.impl.EchoServiceOne" />
</service>
</blueprint>
Java RouteBuilder (route-builder bundle):
public class VerySimpleBuilder extends RouteBuilder {
Echo blueprintServiceReference;
@Override
public void configure() throws Exception {
from("timer://very-simple-builder?period=5000").routeId( "very-simple-route" )
.setBody( simple( "${exchangeProperty[" + Exchange.TIMER_FIRED_TIME + "]}") )
.log("Calling Service via Reference: ${body}" )
.bean(blueprintServiceReference,false)
.to( "mock://result")
.log("Finished" );
}
public Echo getBlueprintServiceReference() {
return blueprintServiceReference;
}
public void setBlueprintServiceReference(Echo blueprintServiceReference) {
this.blueprintServiceReference = blueprintServiceReference;
}
}
Blueprint constructing the Camel context (camel-context bundle):
<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ext="http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0"
xsi:schemaLocation="
http://www.osgi.org/xmlns/blueprint/v1.0.0 http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
http://camel.apache.org/schema/blueprint http://camel.apache.org/schema/blueprint/camel-blueprint.xsd"
>
<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>
</blueprint>
Re: Invoking Dynamic OSGi Blueprint services from a Java RouteBuilder
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
Thank you Ranx -
Unfortunately, I haven’t figured out a way to get around using RouteBuilders for my use case. Since I have a few very common patterns for my routes where the only differences are endpoint configurations and a few other minor things, I can create a few common RouteBuilders and use them to create hundreds of CamelContexts/routes - much like an OSGi ManagedServiceFactory.
I haven’t figured out a clean way to create a route using the Blueprint DSL and then reuse that route with different configurations as of yet, so this is my only option.
As you pointed out though - it’s much easier/faster to test using CamelTestSupport than it is using CamelBlueprintTestSupport, so I like the "Java RouteBuilder deployed using Blueprint" pattern for that as well.
Camel Committers: I guess it’s time for a JIRA issue - is there any particular information you’d like me to include in this issue?
Quinn Stevenson
> On Jan 27, 2016, at 3:22 PM, Ranx <br...@mediadriver.com> wrote:
>
> I've reverted to using blueprint.xml for any service reference calls and
> limiting the routebuilders for now. The part I found most disconcerting
> about this was that the implementation class was being found since it should
> be hidden. That means the classloader is pulling it from a bundle and
> providing it even though the META-INF is explicitly making it private. At
> that point I get the hair raising vision of multiple classloader mechanisms
> loading and instantiating instances in different fashions. I don't have the
> time to look into deeper but I do know I don't want classes leaking out of
> their bundles like that.
>
> In other words, the whole OSGi mechanics are being circumvented. When I
> reverted to blueprint and did a print on the reference I correctly see the
> Proxy class of the interface printed out. That's unfortunate. Using the
> route builders gave me a good way to do testing and get around some of the
> restrictions that CamelBlueprintTestSupport has for multiple CamelContexts.
>
> Would it make sense for CamelBlueprint to preferentially do look ups in the
> OSGi registry and only fall back to looking in the other registries if the
> interface or id is not found? Personally I'd prefer to have a strict mode
> flag that would require items to come out of the OSGi registry when working
> in blueprint.
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Invoking-Dynamic-OSGi-Blueprint-services-from-a-Java-RouteBuilder-tp5776755p5776864.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Invoking Dynamic OSGi Blueprint services from a Java
RouteBuilder
Posted by Ranx <br...@mediadriver.com>.
I've reverted to using blueprint.xml for any service reference calls and
limiting the routebuilders for now. The part I found most disconcerting
about this was that the implementation class was being found since it should
be hidden. That means the classloader is pulling it from a bundle and
providing it even though the META-INF is explicitly making it private. At
that point I get the hair raising vision of multiple classloader mechanisms
loading and instantiating instances in different fashions. I don't have the
time to look into deeper but I do know I don't want classes leaking out of
their bundles like that.
In other words, the whole OSGi mechanics are being circumvented. When I
reverted to blueprint and did a print on the reference I correctly see the
Proxy class of the interface printed out. That's unfortunate. Using the
route builders gave me a good way to do testing and get around some of the
restrictions that CamelBlueprintTestSupport has for multiple CamelContexts.
Would it make sense for CamelBlueprint to preferentially do look ups in the
OSGi registry and only fall back to looking in the other registries if the
interface or id is not found? Personally I'd prefer to have a strict mode
flag that would require items to come out of the OSGi registry when working
in blueprint.
--
View this message in context: http://camel.465427.n5.nabble.com/Invoking-Dynamic-OSGi-Blueprint-services-from-a-Java-RouteBuilder-tp5776755p5776864.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Invoking Dynamic OSGi Blueprint services from a Java RouteBuilder
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
I’m not using the annotations, but it sounds like the same issue.
I tried something else that seems to work - if I use the Bean Component ( http://camel.apache.org/bean.html <http://camel.apache.org/bean.html> ), everything seems to be working as I’d expect.
So if I change my RouteBuilder to look like this:
public class BeanComponentBuilder extends RouteBuilder {
Logger log = LoggerFactory.getLogger(this.getClass());
String blueprintServiceReferenceId;
@Override
public void configure() throws Exception {
from("timer://bean-component-builder?period=5000")
.setBody( simple( "${exchangeProperty[" + Exchange.TIMER_FIRED_TIME + "]}") )
.log("Calling Service via Reference: ${body}" )
.toF( "bean:%s?cache=%b", blueprintServiceReferenceId, false )
.log("Finished" )
.to( "mock://result");
}
public String getBlueprintServiceReferenceId() {
return blueprintServiceReferenceId;
}
public void setBlueprintServiceReferenceId(String blueprintServiceReferenceId) {
this.blueprintServiceReferenceId = blueprintServiceReferenceId;
}
}
And my Blueprint to look like this:
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ext="http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0"
xsi:schemaLocation="
http://www.osgi.org/xmlns/blueprint/v1.0.0 http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
http://camel.apache.org/schema/blueprint http://camel.apache.org/schema/blueprint/camel-blueprint.xsd"
>
<reference id="echo-service" interface="com.pronoia.test.osgi.service.Echo" filter="instance=one" timeout="2000" />
<bean id="bean-component-builder" class="com.pronoia.test.camel.builder.impl.BeanComponentBuilder">
<property name="blueprintServiceReferenceId" value="echo-service" />
</bean>
<camelContext id="bean-component-context" xmlns="http://camel.apache.org/schema/blueprint">
<routeBuilder ref="bean-component-builder" />
</camelContext>
</blueprint>
It seems to work as I’d expect.
However, if I inject the service reference into the RouteBuilder at all, the dynamic behavior is broken.
If I change my RouteBuiler to look like this:
public class BeanComponentBuilder extends RouteBuilder {
Logger log = LoggerFactory.getLogger(this.getClass());
String blueprintServiceReferenceId;
Echo dummyServiceReference;
@Override
public void configure() throws Exception {
from("timer://bean-component-builder?period=5000")
.setBody( simple( "${exchangeProperty[" + Exchange.TIMER_FIRED_TIME + "]}") )
.log("Calling Service via Reference: ${body}" )
.toF( "bean:%s?cache=%b", blueprintServiceReferenceId, false )
.log("Finished" )
.to( "mock://result");
}
public String getBlueprintServiceReferenceId() {
return blueprintServiceReferenceId;
}
public void setBlueprintServiceReferenceId(String blueprintServiceReferenceId) {
this.blueprintServiceReferenceId = blueprintServiceReferenceId;
}
public Echo getDummyServiceReference() {
return dummyServiceReference;
}
public void setDummyServiceReference(Echo dummyServiceReference) {
this.dummyServiceReference = dummyServiceReference;
}
}
And my Blueprint to look like this:
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ext="http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0"
xsi:schemaLocation="
http://www.osgi.org/xmlns/blueprint/v1.0.0 http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
http://camel.apache.org/schema/blueprint http://camel.apache.org/schema/blueprint/camel-blueprint.xsd"
>
<reference id="echo-service" interface="com.pronoia.test.osgi.service.Echo" filter="instance=one" timeout="2000" />
<bean id="bean-component-builder" class="com.pronoia.test.camel.builder.impl.BeanComponentBuilder">
<property name="blueprintServiceReferenceId" value="echo-service" />
<property name="dummyServiceReference" ref="echo-service" />
</bean>
<camelContext id="bean-component-context" xmlns="http://camel.apache.org/schema/blueprint">
<routeBuilder ref="bean-component-builder" />
</camelContext>
</blueprint>
All that’s different between the two is the reference to the service is injected into the route builder - but it’s never used.
Quinn Stevenson
> On Jan 27, 2016, at 10:32 AM, Ranx <br...@mediadriver.com> wrote:
>
> This is serendipitous as I've recently run into this as well. I switched
> from straight Blueprint routes and instantiation to using blueprint to
> bootstrap the routebuilder(s). But the injection of the reference to the
> service from blueprint doesn't appear to be proxied as I see the concrete
> class and the hot swapping isn't working as expected.
>
> If I'm understanding this correctly it doesn't matter if the route builder
> is bootstrapped through blueprint it is still going to use the simple
> registry mechanics instead of the OSGi service registry. In bundle A I have
> blueprint that looks like:
>
> <service interface="my.services.api.InvoiceDocumentService">
> <bean class="my.services.test.internal.TestInvoiceServiceImpl" />
> </service>
>
> In bundle B I have this startup.
> <camelContext xmlns="http://camel.apache.org/schema/blueprint">
> <package>my.routes.internal</package>
> </camelContext>
>
> In the routes package I have an @BeanInject for the
> my.services.api.InvoiceDocumentService. They live in different bundles and
> the internals are not exported. But when I do a .getClass().getName on the
> service api received in bundle B it shows the implementation class. I don't
> believe that's the proxy class.
>
> So it appears that using this mechanic is skirting the OSGi service proxying
> mechanism. Is that a correct assessment?
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Invoking-Dynamic-OSGi-Blueprint-services-from-a-Java-RouteBuilder-tp5776755p5776848.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Invoking Dynamic OSGi Blueprint services from a Java
RouteBuilder
Posted by Ranx <br...@mediadriver.com>.
This is serendipitous as I've recently run into this as well. I switched
from straight Blueprint routes and instantiation to using blueprint to
bootstrap the routebuilder(s). But the injection of the reference to the
service from blueprint doesn't appear to be proxied as I see the concrete
class and the hot swapping isn't working as expected.
If I'm understanding this correctly it doesn't matter if the route builder
is bootstrapped through blueprint it is still going to use the simple
registry mechanics instead of the OSGi service registry. In bundle A I have
blueprint that looks like:
<service interface="my.services.api.InvoiceDocumentService">
<bean class="my.services.test.internal.TestInvoiceServiceImpl" />
</service>
In bundle B I have this startup.
<camelContext xmlns="http://camel.apache.org/schema/blueprint">
<package>my.routes.internal</package>
</camelContext>
In the routes package I have an @BeanInject for the
my.services.api.InvoiceDocumentService. They live in different bundles and
the internals are not exported. But when I do a .getClass().getName on the
service api received in bundle B it shows the implementation class. I don't
believe that's the proxy class.
So it appears that using this mechanic is skirting the OSGi service proxying
mechanism. Is that a correct assessment?
--
View this message in context: http://camel.465427.n5.nabble.com/Invoking-Dynamic-OSGi-Blueprint-services-from-a-Java-RouteBuilder-tp5776755p5776848.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Invoking Dynamic OSGi Blueprint services from a Java RouteBuilder
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
Do you have an idea of how to fix this? If you can point me in the right direction, I’d be happy to get a PR going for it.
Quinn Stevenson
quinn@pronoia-solutions.com
(801) 244-7758
> On Feb 2, 2016, at 10:05 AM, Brad Johnson <br...@mediadriver.com> wrote:
>
> And if we get enough up votes maybe it'll get put in. It shouldn't be too
> difficult technically and can be put in without breaking anyone. Now, what
> happens when the flag gets turned on will be interesting.
>
> On Tue, Feb 2, 2016 at 11:02 AM, Brad Johnson <br...@mediadriver.com>
> wrote:
>
>> Tack the examples on to the issue to give it context.. That'll help folks
>> replicate it.
>>
>> On Tue, Feb 2, 2016 at 11:01 AM, Quinn Stevenson <
>> quinn@pronoia-solutions.com> wrote:
>>
>>> Thank You for opening the issue Brad -
>>>
>>> You beat me to it, but you’re explanation of the issue was much better
>>> than I could come up with - all I have are samples of what’s going on and
>>> no real explanation as to why :-)
>>>
>>> Thanks Again
>>>
>>>
>>>> On Feb 2, 2016, at 9:51 AM, Brad Johnson <br...@mediadriver.com>
>>> wrote:
>>>>
>>>> https://issues.apache.org/jira/browse/CAMEL-9562
>>>>
>>>> I've opened an issue. I think it is a relatively easy thing to add a
>>>> strict mode flag without breaking anyone. You're right that it is easy
>>>> enough to make it work right. But if I haven't set something up to work
>>>> correctly I don't want the classloader fixing it inadvertently.
>>>>
>>>> I haven't run into this before since for the past two years I've used
>>> Camel
>>>> blueprint XML exclusively and only used Java for a beans and service
>>>> calls. I was venturing into using route builders when I ran into this.
>>>>
>>>> On Tue, Feb 2, 2016 at 10:40 AM, Quinn Stevenson <
>>>> quinn@pronoia-solutions.com> wrote:
>>>>
>>>>> Thank You Christian -
>>>>>
>>>>> Yes - I pointed out that if I used the Bean Component, everything
>>> seemed
>>>>> to work as I expected.
>>>>>
>>>>> The problem I have is I use beans in filter blocks as well, and there I
>>>>> can’t use the 'to( “bean://<name” )’ construct. I need to keep the
>>>>> original message bodies and just filter, and when I use the method(…)
>>>>> invocation, it’s hit or miss if it honors dynamic services (i.e.
>>> picks-up
>>>>> new instances when the implementation is replaced). It’s very
>>> sensitive to
>>>>> how the bean with the service reference is declared.
>>>>>
>>>>> I also tried using enrich( “bean://<bean-name>” ) with an aggregation
>>>>> strategy to get around this, but it worked the same way as the method(
>>> … )
>>>>> DSL - it didn’t pickup new service instances when the services were
>>>>> replaced.
>>>>>
>>>>>
>>>>>
>>>>>> On Feb 2, 2016, at 2:24 AM, Christian Schneider <
>>> chris@die-schneider.net>
>>>>> wrote:
>>>>>>
>>>>>> There is a much simpler way to use an OSGi service with blueprint.
>>>>>> Simply use the bean component of camel. It resolves beans against the
>>>>> camel registry.
>>>>>> When you define your camel context using blueprint then the camel
>>>>> registry automatically includes all blueprint beans.
>>>>>>
>>>>>> So you can do this in java dsl:
>>>>>> to("bean:echo-service")
>>>>>>
>>>>>> It will find the bean with this id in blueprint. In your case it will
>>> be
>>>>> the service reference.
>>>>>>
>>>>>> Christian
>>>>>>
>>>>>> On 26.01.2016 23:11, Quinn Stevenson wrote:
>>>>>>> When I use an OSGi Service registered using Blueprint from a Java
>>> route
>>>>> (built using a Java RouteBuilder), the Camel route isn’t detecting the
>>> when
>>>>> the service is not available, and it isn’t updating when the service
>>>>> implementation changes.
>>>>>>>
>>>>>>> The simple setup I’m using has a Java interface for the OSGi service
>>> in
>>>>> one bundle, and implementation of that interface which uses Blueprint
>>> to
>>>>> register the service in another bundle, and simple RouteBuilder that
>>> uses
>>>>> the service in a third bundle. The implementation of the service is
>>>>> injected into the RouteBuilder using Blueprint, and the Camel context
>>> is
>>>>> configured in Blueprint in a fourth bundle.
>>>>>>>
>>>>>>> After all these bundles are installed and started in Karaf, the run
>>> and
>>>>> the hashCode of service is logged every time the Camel timer fires and
>>>>> triggers an exchange. If I stop the bundle that registers the service
>>>>> using Blueprint, the route continues to log the same hashCode when it
>>> calls
>>>>> the OSGi service. I would expect a ServiceUnavailableException after a
>>>>> timeout.
>>>>>>>
>>>>>>> Additionally, when I restart the bundle that registers the service
>>>>> object, I continue to get the same hashCode. I would expect to get a
>>> new
>>>>> hashCode value.
>>>>>>>
>>>>>>> Am I doing something wrong? Do I need to do something different do
>>> get
>>>>> the dynamic behavior I’m looking for?
>>>>>>>
>>>>>>>
>>>>>>> The code looks like this:
>>>>>>>
>>>>>>> Java Interface (service-interface bundle):
>>>>>>> public interface Echo {
>>>>>>> String execute(String body);
>>>>>>> }
>>>>>>>
>>>>>>> Java Implementation:
>>>>>>> public class EchoServiceOne implements Echo {
>>>>>>> Logger log = LoggerFactory.getLogger(this.getClass());
>>>>>>>
>>>>>>> @Override
>>>>>>> public String execute(String body) {
>>>>>>> log.info( "{}:{} -> execute",
>>> this.getClass().getSimpleName(),
>>>>> this.hashCode() );
>>>>>>> return body;
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> Blueprint Registering the service (service-one bundle):
>>>>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>>>>> <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
>>>>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>>>>> xsi:schemaLocation="
>>>>> http://www.osgi.org/xmlns/blueprint/v1.0.0
>>>>> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd">
>>>>>>>
>>>>>>> <service interface="com.pronoia.test.osgi.service.Echo" >
>>>>>>> <service-properties>
>>>>>>> <entry key="instance" value="one" />
>>>>>>> </service-properties>
>>>>>>> <bean
>>> class="com.pronoia.test.osgi.service.impl.EchoServiceOne"
>>>>> />
>>>>>>> </service>
>>>>>>>
>>>>>>> </blueprint>
>>>>>>>
>>>>>>> Java RouteBuilder (route-builder bundle):
>>>>>>> public class VerySimpleBuilder extends RouteBuilder {
>>>>>>> Echo blueprintServiceReference;
>>>>>>>
>>>>>>> @Override
>>>>>>> public void configure() throws Exception {
>>>>>>> from("timer://very-simple-builder?period=5000").routeId(
>>>>> "very-simple-route" )
>>>>>>> .setBody( simple( "${exchangeProperty[" +
>>>>> Exchange.TIMER_FIRED_TIME + "]}") )
>>>>>>> .log("Calling Service via Reference: ${body}" )
>>>>>>> .bean(blueprintServiceReference,false)
>>>>>>> .to( "mock://result")
>>>>>>> .log("Finished" );
>>>>>>> }
>>>>>>>
>>>>>>> public Echo getBlueprintServiceReference() {
>>>>>>> return blueprintServiceReference;
>>>>>>> }
>>>>>>>
>>>>>>> public void setBlueprintServiceReference(Echo
>>>>> blueprintServiceReference) {
>>>>>>> this.blueprintServiceReference = blueprintServiceReference;
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> Blueprint constructing the Camel context (camel-context bundle):
>>>>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>>>>> <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
>>>>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>>>>> xmlns:ext="
>>>>> http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0"
>>>>>>> xsi:schemaLocation="
>>>>>>> http://www.osgi.org/xmlns/blueprint/v1.0.0
>>>>> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
>>>>>>> http://camel.apache.org/schema/blueprint
>>>>> http://camel.apache.org/schema/blueprint/camel-blueprint.xsd"
>>>>>>> <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>
>>>>>>>
>>>>>>> </blueprint>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Christian Schneider
>>>>>> http://www.liquid-reality.de
>>>>>>
>>>>>> Open Source Architect
>>>>>> http://www.talend.com
>>>>>>
>>>>>
>>>>>
>>>
>>>
>>
Re: Invoking Dynamic OSGi Blueprint services from a Java RouteBuilder
Posted by Brad Johnson <br...@mediadriver.com>.
And if we get enough up votes maybe it'll get put in. It shouldn't be too
difficult technically and can be put in without breaking anyone. Now, what
happens when the flag gets turned on will be interesting.
On Tue, Feb 2, 2016 at 11:02 AM, Brad Johnson <br...@mediadriver.com>
wrote:
> Tack the examples on to the issue to give it context.. That'll help folks
> replicate it.
>
> On Tue, Feb 2, 2016 at 11:01 AM, Quinn Stevenson <
> quinn@pronoia-solutions.com> wrote:
>
>> Thank You for opening the issue Brad -
>>
>> You beat me to it, but you’re explanation of the issue was much better
>> than I could come up with - all I have are samples of what’s going on and
>> no real explanation as to why :-)
>>
>> Thanks Again
>>
>>
>> > On Feb 2, 2016, at 9:51 AM, Brad Johnson <br...@mediadriver.com>
>> wrote:
>> >
>> > https://issues.apache.org/jira/browse/CAMEL-9562
>> >
>> > I've opened an issue. I think it is a relatively easy thing to add a
>> > strict mode flag without breaking anyone. You're right that it is easy
>> > enough to make it work right. But if I haven't set something up to work
>> > correctly I don't want the classloader fixing it inadvertently.
>> >
>> > I haven't run into this before since for the past two years I've used
>> Camel
>> > blueprint XML exclusively and only used Java for a beans and service
>> > calls. I was venturing into using route builders when I ran into this.
>> >
>> > On Tue, Feb 2, 2016 at 10:40 AM, Quinn Stevenson <
>> > quinn@pronoia-solutions.com> wrote:
>> >
>> >> Thank You Christian -
>> >>
>> >> Yes - I pointed out that if I used the Bean Component, everything
>> seemed
>> >> to work as I expected.
>> >>
>> >> The problem I have is I use beans in filter blocks as well, and there I
>> >> can’t use the 'to( “bean://<name” )’ construct. I need to keep the
>> >> original message bodies and just filter, and when I use the method(…)
>> >> invocation, it’s hit or miss if it honors dynamic services (i.e.
>> picks-up
>> >> new instances when the implementation is replaced). It’s very
>> sensitive to
>> >> how the bean with the service reference is declared.
>> >>
>> >> I also tried using enrich( “bean://<bean-name>” ) with an aggregation
>> >> strategy to get around this, but it worked the same way as the method(
>> … )
>> >> DSL - it didn’t pickup new service instances when the services were
>> >> replaced.
>> >>
>> >>
>> >>
>> >>> On Feb 2, 2016, at 2:24 AM, Christian Schneider <
>> chris@die-schneider.net>
>> >> wrote:
>> >>>
>> >>> There is a much simpler way to use an OSGi service with blueprint.
>> >>> Simply use the bean component of camel. It resolves beans against the
>> >> camel registry.
>> >>> When you define your camel context using blueprint then the camel
>> >> registry automatically includes all blueprint beans.
>> >>>
>> >>> So you can do this in java dsl:
>> >>> to("bean:echo-service")
>> >>>
>> >>> It will find the bean with this id in blueprint. In your case it will
>> be
>> >> the service reference.
>> >>>
>> >>> Christian
>> >>>
>> >>> On 26.01.2016 23:11, Quinn Stevenson wrote:
>> >>>> When I use an OSGi Service registered using Blueprint from a Java
>> route
>> >> (built using a Java RouteBuilder), the Camel route isn’t detecting the
>> when
>> >> the service is not available, and it isn’t updating when the service
>> >> implementation changes.
>> >>>>
>> >>>> The simple setup I’m using has a Java interface for the OSGi service
>> in
>> >> one bundle, and implementation of that interface which uses Blueprint
>> to
>> >> register the service in another bundle, and simple RouteBuilder that
>> uses
>> >> the service in a third bundle. The implementation of the service is
>> >> injected into the RouteBuilder using Blueprint, and the Camel context
>> is
>> >> configured in Blueprint in a fourth bundle.
>> >>>>
>> >>>> After all these bundles are installed and started in Karaf, the run
>> and
>> >> the hashCode of service is logged every time the Camel timer fires and
>> >> triggers an exchange. If I stop the bundle that registers the service
>> >> using Blueprint, the route continues to log the same hashCode when it
>> calls
>> >> the OSGi service. I would expect a ServiceUnavailableException after a
>> >> timeout.
>> >>>>
>> >>>> Additionally, when I restart the bundle that registers the service
>> >> object, I continue to get the same hashCode. I would expect to get a
>> new
>> >> hashCode value.
>> >>>>
>> >>>> Am I doing something wrong? Do I need to do something different do
>> get
>> >> the dynamic behavior I’m looking for?
>> >>>>
>> >>>>
>> >>>> The code looks like this:
>> >>>>
>> >>>> Java Interface (service-interface bundle):
>> >>>> public interface Echo {
>> >>>> String execute(String body);
>> >>>> }
>> >>>>
>> >>>> Java Implementation:
>> >>>> public class EchoServiceOne implements Echo {
>> >>>> Logger log = LoggerFactory.getLogger(this.getClass());
>> >>>>
>> >>>> @Override
>> >>>> public String execute(String body) {
>> >>>> log.info( "{}:{} -> execute",
>> this.getClass().getSimpleName(),
>> >> this.hashCode() );
>> >>>> return body;
>> >>>> }
>> >>>> }
>> >>>>
>> >>>>
>> >>>> Blueprint Registering the service (service-one bundle):
>> >>>> <?xml version="1.0" encoding="UTF-8"?>
>> >>>> <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
>> >>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> >>>> xsi:schemaLocation="
>> >> http://www.osgi.org/xmlns/blueprint/v1.0.0
>> >> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd">
>> >>>>
>> >>>> <service interface="com.pronoia.test.osgi.service.Echo" >
>> >>>> <service-properties>
>> >>>> <entry key="instance" value="one" />
>> >>>> </service-properties>
>> >>>> <bean
>> class="com.pronoia.test.osgi.service.impl.EchoServiceOne"
>> >> />
>> >>>> </service>
>> >>>>
>> >>>> </blueprint>
>> >>>>
>> >>>> Java RouteBuilder (route-builder bundle):
>> >>>> public class VerySimpleBuilder extends RouteBuilder {
>> >>>> Echo blueprintServiceReference;
>> >>>>
>> >>>> @Override
>> >>>> public void configure() throws Exception {
>> >>>> from("timer://very-simple-builder?period=5000").routeId(
>> >> "very-simple-route" )
>> >>>> .setBody( simple( "${exchangeProperty[" +
>> >> Exchange.TIMER_FIRED_TIME + "]}") )
>> >>>> .log("Calling Service via Reference: ${body}" )
>> >>>> .bean(blueprintServiceReference,false)
>> >>>> .to( "mock://result")
>> >>>> .log("Finished" );
>> >>>> }
>> >>>>
>> >>>> public Echo getBlueprintServiceReference() {
>> >>>> return blueprintServiceReference;
>> >>>> }
>> >>>>
>> >>>> public void setBlueprintServiceReference(Echo
>> >> blueprintServiceReference) {
>> >>>> this.blueprintServiceReference = blueprintServiceReference;
>> >>>> }
>> >>>> }
>> >>>>
>> >>>> Blueprint constructing the Camel context (camel-context bundle):
>> >>>> <?xml version="1.0" encoding="UTF-8"?>
>> >>>> <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
>> >>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> >>>> xmlns:ext="
>> >> http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0"
>> >>>> xsi:schemaLocation="
>> >>>> http://www.osgi.org/xmlns/blueprint/v1.0.0
>> >> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
>> >>>> http://camel.apache.org/schema/blueprint
>> >> http://camel.apache.org/schema/blueprint/camel-blueprint.xsd"
>> >>>> <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>
>> >>>>
>> >>>> </blueprint>
>> >>>>
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>> --
>> >>> Christian Schneider
>> >>> http://www.liquid-reality.de
>> >>>
>> >>> Open Source Architect
>> >>> http://www.talend.com
>> >>>
>> >>
>> >>
>>
>>
>
Re: Invoking Dynamic OSGi Blueprint services from a Java RouteBuilder
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
Will do - I’ll pull them from this thread.
Thanks Again - this one is killing me right now
> On Feb 2, 2016, at 10:02 AM, Brad Johnson <br...@mediadriver.com> wrote:
>
> Tack the examples on to the issue to give it context.. That'll help folks
> replicate it.
>
> On Tue, Feb 2, 2016 at 11:01 AM, Quinn Stevenson <
> quinn@pronoia-solutions.com> wrote:
>
>> Thank You for opening the issue Brad -
>>
>> You beat me to it, but you’re explanation of the issue was much better
>> than I could come up with - all I have are samples of what’s going on and
>> no real explanation as to why :-)
>>
>> Thanks Again
>>
>>
>>> On Feb 2, 2016, at 9:51 AM, Brad Johnson <br...@mediadriver.com>
>> wrote:
>>>
>>> https://issues.apache.org/jira/browse/CAMEL-9562
>>>
>>> I've opened an issue. I think it is a relatively easy thing to add a
>>> strict mode flag without breaking anyone. You're right that it is easy
>>> enough to make it work right. But if I haven't set something up to work
>>> correctly I don't want the classloader fixing it inadvertently.
>>>
>>> I haven't run into this before since for the past two years I've used
>> Camel
>>> blueprint XML exclusively and only used Java for a beans and service
>>> calls. I was venturing into using route builders when I ran into this.
>>>
>>> On Tue, Feb 2, 2016 at 10:40 AM, Quinn Stevenson <
>>> quinn@pronoia-solutions.com> wrote:
>>>
>>>> Thank You Christian -
>>>>
>>>> Yes - I pointed out that if I used the Bean Component, everything seemed
>>>> to work as I expected.
>>>>
>>>> The problem I have is I use beans in filter blocks as well, and there I
>>>> can’t use the 'to( “bean://<name” )’ construct. I need to keep the
>>>> original message bodies and just filter, and when I use the method(…)
>>>> invocation, it’s hit or miss if it honors dynamic services (i.e.
>> picks-up
>>>> new instances when the implementation is replaced). It’s very
>> sensitive to
>>>> how the bean with the service reference is declared.
>>>>
>>>> I also tried using enrich( “bean://<bean-name>” ) with an aggregation
>>>> strategy to get around this, but it worked the same way as the method(
>> … )
>>>> DSL - it didn’t pickup new service instances when the services were
>>>> replaced.
>>>>
>>>>
>>>>
>>>>> On Feb 2, 2016, at 2:24 AM, Christian Schneider <
>> chris@die-schneider.net>
>>>> wrote:
>>>>>
>>>>> There is a much simpler way to use an OSGi service with blueprint.
>>>>> Simply use the bean component of camel. It resolves beans against the
>>>> camel registry.
>>>>> When you define your camel context using blueprint then the camel
>>>> registry automatically includes all blueprint beans.
>>>>>
>>>>> So you can do this in java dsl:
>>>>> to("bean:echo-service")
>>>>>
>>>>> It will find the bean with this id in blueprint. In your case it will
>> be
>>>> the service reference.
>>>>>
>>>>> Christian
>>>>>
>>>>> On 26.01.2016 23:11, Quinn Stevenson wrote:
>>>>>> When I use an OSGi Service registered using Blueprint from a Java
>> route
>>>> (built using a Java RouteBuilder), the Camel route isn’t detecting the
>> when
>>>> the service is not available, and it isn’t updating when the service
>>>> implementation changes.
>>>>>>
>>>>>> The simple setup I’m using has a Java interface for the OSGi service
>> in
>>>> one bundle, and implementation of that interface which uses Blueprint to
>>>> register the service in another bundle, and simple RouteBuilder that
>> uses
>>>> the service in a third bundle. The implementation of the service is
>>>> injected into the RouteBuilder using Blueprint, and the Camel context is
>>>> configured in Blueprint in a fourth bundle.
>>>>>>
>>>>>> After all these bundles are installed and started in Karaf, the run
>> and
>>>> the hashCode of service is logged every time the Camel timer fires and
>>>> triggers an exchange. If I stop the bundle that registers the service
>>>> using Blueprint, the route continues to log the same hashCode when it
>> calls
>>>> the OSGi service. I would expect a ServiceUnavailableException after a
>>>> timeout.
>>>>>>
>>>>>> Additionally, when I restart the bundle that registers the service
>>>> object, I continue to get the same hashCode. I would expect to get a
>> new
>>>> hashCode value.
>>>>>>
>>>>>> Am I doing something wrong? Do I need to do something different do
>> get
>>>> the dynamic behavior I’m looking for?
>>>>>>
>>>>>>
>>>>>> The code looks like this:
>>>>>>
>>>>>> Java Interface (service-interface bundle):
>>>>>> public interface Echo {
>>>>>> String execute(String body);
>>>>>> }
>>>>>>
>>>>>> Java Implementation:
>>>>>> public class EchoServiceOne implements Echo {
>>>>>> Logger log = LoggerFactory.getLogger(this.getClass());
>>>>>>
>>>>>> @Override
>>>>>> public String execute(String body) {
>>>>>> log.info( "{}:{} -> execute", this.getClass().getSimpleName(),
>>>> this.hashCode() );
>>>>>> return body;
>>>>>> }
>>>>>> }
>>>>>>
>>>>>>
>>>>>> Blueprint Registering the service (service-one bundle):
>>>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>>>> <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
>>>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>>>> xsi:schemaLocation="
>>>> http://www.osgi.org/xmlns/blueprint/v1.0.0
>>>> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd">
>>>>>>
>>>>>> <service interface="com.pronoia.test.osgi.service.Echo" >
>>>>>> <service-properties>
>>>>>> <entry key="instance" value="one" />
>>>>>> </service-properties>
>>>>>> <bean class="com.pronoia.test.osgi.service.impl.EchoServiceOne"
>>>> />
>>>>>> </service>
>>>>>>
>>>>>> </blueprint>
>>>>>>
>>>>>> Java RouteBuilder (route-builder bundle):
>>>>>> public class VerySimpleBuilder extends RouteBuilder {
>>>>>> Echo blueprintServiceReference;
>>>>>>
>>>>>> @Override
>>>>>> public void configure() throws Exception {
>>>>>> from("timer://very-simple-builder?period=5000").routeId(
>>>> "very-simple-route" )
>>>>>> .setBody( simple( "${exchangeProperty[" +
>>>> Exchange.TIMER_FIRED_TIME + "]}") )
>>>>>> .log("Calling Service via Reference: ${body}" )
>>>>>> .bean(blueprintServiceReference,false)
>>>>>> .to( "mock://result")
>>>>>> .log("Finished" );
>>>>>> }
>>>>>>
>>>>>> public Echo getBlueprintServiceReference() {
>>>>>> return blueprintServiceReference;
>>>>>> }
>>>>>>
>>>>>> public void setBlueprintServiceReference(Echo
>>>> blueprintServiceReference) {
>>>>>> this.blueprintServiceReference = blueprintServiceReference;
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> Blueprint constructing the Camel context (camel-context bundle):
>>>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>>>> <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
>>>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>>>> xmlns:ext="
>>>> http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0"
>>>>>> xsi:schemaLocation="
>>>>>> http://www.osgi.org/xmlns/blueprint/v1.0.0
>>>> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
>>>>>> http://camel.apache.org/schema/blueprint
>>>> http://camel.apache.org/schema/blueprint/camel-blueprint.xsd"
>>>>>> <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>
>>>>>>
>>>>>> </blueprint>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Christian Schneider
>>>>> http://www.liquid-reality.de
>>>>>
>>>>> Open Source Architect
>>>>> http://www.talend.com
>>>>>
>>>>
>>>>
>>
>>
Re: Invoking Dynamic OSGi Blueprint services from a Java RouteBuilder
Posted by Brad Johnson <br...@mediadriver.com>.
Tack the examples on to the issue to give it context.. That'll help folks
replicate it.
On Tue, Feb 2, 2016 at 11:01 AM, Quinn Stevenson <
quinn@pronoia-solutions.com> wrote:
> Thank You for opening the issue Brad -
>
> You beat me to it, but you’re explanation of the issue was much better
> than I could come up with - all I have are samples of what’s going on and
> no real explanation as to why :-)
>
> Thanks Again
>
>
> > On Feb 2, 2016, at 9:51 AM, Brad Johnson <br...@mediadriver.com>
> wrote:
> >
> > https://issues.apache.org/jira/browse/CAMEL-9562
> >
> > I've opened an issue. I think it is a relatively easy thing to add a
> > strict mode flag without breaking anyone. You're right that it is easy
> > enough to make it work right. But if I haven't set something up to work
> > correctly I don't want the classloader fixing it inadvertently.
> >
> > I haven't run into this before since for the past two years I've used
> Camel
> > blueprint XML exclusively and only used Java for a beans and service
> > calls. I was venturing into using route builders when I ran into this.
> >
> > On Tue, Feb 2, 2016 at 10:40 AM, Quinn Stevenson <
> > quinn@pronoia-solutions.com> wrote:
> >
> >> Thank You Christian -
> >>
> >> Yes - I pointed out that if I used the Bean Component, everything seemed
> >> to work as I expected.
> >>
> >> The problem I have is I use beans in filter blocks as well, and there I
> >> can’t use the 'to( “bean://<name” )’ construct. I need to keep the
> >> original message bodies and just filter, and when I use the method(…)
> >> invocation, it’s hit or miss if it honors dynamic services (i.e.
> picks-up
> >> new instances when the implementation is replaced). It’s very
> sensitive to
> >> how the bean with the service reference is declared.
> >>
> >> I also tried using enrich( “bean://<bean-name>” ) with an aggregation
> >> strategy to get around this, but it worked the same way as the method(
> … )
> >> DSL - it didn’t pickup new service instances when the services were
> >> replaced.
> >>
> >>
> >>
> >>> On Feb 2, 2016, at 2:24 AM, Christian Schneider <
> chris@die-schneider.net>
> >> wrote:
> >>>
> >>> There is a much simpler way to use an OSGi service with blueprint.
> >>> Simply use the bean component of camel. It resolves beans against the
> >> camel registry.
> >>> When you define your camel context using blueprint then the camel
> >> registry automatically includes all blueprint beans.
> >>>
> >>> So you can do this in java dsl:
> >>> to("bean:echo-service")
> >>>
> >>> It will find the bean with this id in blueprint. In your case it will
> be
> >> the service reference.
> >>>
> >>> Christian
> >>>
> >>> On 26.01.2016 23:11, Quinn Stevenson wrote:
> >>>> When I use an OSGi Service registered using Blueprint from a Java
> route
> >> (built using a Java RouteBuilder), the Camel route isn’t detecting the
> when
> >> the service is not available, and it isn’t updating when the service
> >> implementation changes.
> >>>>
> >>>> The simple setup I’m using has a Java interface for the OSGi service
> in
> >> one bundle, and implementation of that interface which uses Blueprint to
> >> register the service in another bundle, and simple RouteBuilder that
> uses
> >> the service in a third bundle. The implementation of the service is
> >> injected into the RouteBuilder using Blueprint, and the Camel context is
> >> configured in Blueprint in a fourth bundle.
> >>>>
> >>>> After all these bundles are installed and started in Karaf, the run
> and
> >> the hashCode of service is logged every time the Camel timer fires and
> >> triggers an exchange. If I stop the bundle that registers the service
> >> using Blueprint, the route continues to log the same hashCode when it
> calls
> >> the OSGi service. I would expect a ServiceUnavailableException after a
> >> timeout.
> >>>>
> >>>> Additionally, when I restart the bundle that registers the service
> >> object, I continue to get the same hashCode. I would expect to get a
> new
> >> hashCode value.
> >>>>
> >>>> Am I doing something wrong? Do I need to do something different do
> get
> >> the dynamic behavior I’m looking for?
> >>>>
> >>>>
> >>>> The code looks like this:
> >>>>
> >>>> Java Interface (service-interface bundle):
> >>>> public interface Echo {
> >>>> String execute(String body);
> >>>> }
> >>>>
> >>>> Java Implementation:
> >>>> public class EchoServiceOne implements Echo {
> >>>> Logger log = LoggerFactory.getLogger(this.getClass());
> >>>>
> >>>> @Override
> >>>> public String execute(String body) {
> >>>> log.info( "{}:{} -> execute", this.getClass().getSimpleName(),
> >> this.hashCode() );
> >>>> return body;
> >>>> }
> >>>> }
> >>>>
> >>>>
> >>>> Blueprint Registering the service (service-one bundle):
> >>>> <?xml version="1.0" encoding="UTF-8"?>
> >>>> <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
> >>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> >>>> xsi:schemaLocation="
> >> http://www.osgi.org/xmlns/blueprint/v1.0.0
> >> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd">
> >>>>
> >>>> <service interface="com.pronoia.test.osgi.service.Echo" >
> >>>> <service-properties>
> >>>> <entry key="instance" value="one" />
> >>>> </service-properties>
> >>>> <bean class="com.pronoia.test.osgi.service.impl.EchoServiceOne"
> >> />
> >>>> </service>
> >>>>
> >>>> </blueprint>
> >>>>
> >>>> Java RouteBuilder (route-builder bundle):
> >>>> public class VerySimpleBuilder extends RouteBuilder {
> >>>> Echo blueprintServiceReference;
> >>>>
> >>>> @Override
> >>>> public void configure() throws Exception {
> >>>> from("timer://very-simple-builder?period=5000").routeId(
> >> "very-simple-route" )
> >>>> .setBody( simple( "${exchangeProperty[" +
> >> Exchange.TIMER_FIRED_TIME + "]}") )
> >>>> .log("Calling Service via Reference: ${body}" )
> >>>> .bean(blueprintServiceReference,false)
> >>>> .to( "mock://result")
> >>>> .log("Finished" );
> >>>> }
> >>>>
> >>>> public Echo getBlueprintServiceReference() {
> >>>> return blueprintServiceReference;
> >>>> }
> >>>>
> >>>> public void setBlueprintServiceReference(Echo
> >> blueprintServiceReference) {
> >>>> this.blueprintServiceReference = blueprintServiceReference;
> >>>> }
> >>>> }
> >>>>
> >>>> Blueprint constructing the Camel context (camel-context bundle):
> >>>> <?xml version="1.0" encoding="UTF-8"?>
> >>>> <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
> >>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> >>>> xmlns:ext="
> >> http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0"
> >>>> xsi:schemaLocation="
> >>>> http://www.osgi.org/xmlns/blueprint/v1.0.0
> >> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
> >>>> http://camel.apache.org/schema/blueprint
> >> http://camel.apache.org/schema/blueprint/camel-blueprint.xsd"
> >>>> <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>
> >>>>
> >>>> </blueprint>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Christian Schneider
> >>> http://www.liquid-reality.de
> >>>
> >>> Open Source Architect
> >>> http://www.talend.com
> >>>
> >>
> >>
>
>
Re: Invoking Dynamic OSGi Blueprint services from a Java RouteBuilder
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
Thank You for opening the issue Brad -
You beat me to it, but you’re explanation of the issue was much better than I could come up with - all I have are samples of what’s going on and no real explanation as to why :-)
Thanks Again
> On Feb 2, 2016, at 9:51 AM, Brad Johnson <br...@mediadriver.com> wrote:
>
> https://issues.apache.org/jira/browse/CAMEL-9562
>
> I've opened an issue. I think it is a relatively easy thing to add a
> strict mode flag without breaking anyone. You're right that it is easy
> enough to make it work right. But if I haven't set something up to work
> correctly I don't want the classloader fixing it inadvertently.
>
> I haven't run into this before since for the past two years I've used Camel
> blueprint XML exclusively and only used Java for a beans and service
> calls. I was venturing into using route builders when I ran into this.
>
> On Tue, Feb 2, 2016 at 10:40 AM, Quinn Stevenson <
> quinn@pronoia-solutions.com> wrote:
>
>> Thank You Christian -
>>
>> Yes - I pointed out that if I used the Bean Component, everything seemed
>> to work as I expected.
>>
>> The problem I have is I use beans in filter blocks as well, and there I
>> can’t use the 'to( “bean://<name” )’ construct. I need to keep the
>> original message bodies and just filter, and when I use the method(…)
>> invocation, it’s hit or miss if it honors dynamic services (i.e. picks-up
>> new instances when the implementation is replaced). It’s very sensitive to
>> how the bean with the service reference is declared.
>>
>> I also tried using enrich( “bean://<bean-name>” ) with an aggregation
>> strategy to get around this, but it worked the same way as the method( … )
>> DSL - it didn’t pickup new service instances when the services were
>> replaced.
>>
>>
>>
>>> On Feb 2, 2016, at 2:24 AM, Christian Schneider <ch...@die-schneider.net>
>> wrote:
>>>
>>> There is a much simpler way to use an OSGi service with blueprint.
>>> Simply use the bean component of camel. It resolves beans against the
>> camel registry.
>>> When you define your camel context using blueprint then the camel
>> registry automatically includes all blueprint beans.
>>>
>>> So you can do this in java dsl:
>>> to("bean:echo-service")
>>>
>>> It will find the bean with this id in blueprint. In your case it will be
>> the service reference.
>>>
>>> Christian
>>>
>>> On 26.01.2016 23:11, Quinn Stevenson wrote:
>>>> When I use an OSGi Service registered using Blueprint from a Java route
>> (built using a Java RouteBuilder), the Camel route isn’t detecting the when
>> the service is not available, and it isn’t updating when the service
>> implementation changes.
>>>>
>>>> The simple setup I’m using has a Java interface for the OSGi service in
>> one bundle, and implementation of that interface which uses Blueprint to
>> register the service in another bundle, and simple RouteBuilder that uses
>> the service in a third bundle. The implementation of the service is
>> injected into the RouteBuilder using Blueprint, and the Camel context is
>> configured in Blueprint in a fourth bundle.
>>>>
>>>> After all these bundles are installed and started in Karaf, the run and
>> the hashCode of service is logged every time the Camel timer fires and
>> triggers an exchange. If I stop the bundle that registers the service
>> using Blueprint, the route continues to log the same hashCode when it calls
>> the OSGi service. I would expect a ServiceUnavailableException after a
>> timeout.
>>>>
>>>> Additionally, when I restart the bundle that registers the service
>> object, I continue to get the same hashCode. I would expect to get a new
>> hashCode value.
>>>>
>>>> Am I doing something wrong? Do I need to do something different do get
>> the dynamic behavior I’m looking for?
>>>>
>>>>
>>>> The code looks like this:
>>>>
>>>> Java Interface (service-interface bundle):
>>>> public interface Echo {
>>>> String execute(String body);
>>>> }
>>>>
>>>> Java Implementation:
>>>> public class EchoServiceOne implements Echo {
>>>> Logger log = LoggerFactory.getLogger(this.getClass());
>>>>
>>>> @Override
>>>> public String execute(String body) {
>>>> log.info( "{}:{} -> execute", this.getClass().getSimpleName(),
>> this.hashCode() );
>>>> return body;
>>>> }
>>>> }
>>>>
>>>>
>>>> Blueprint Registering the service (service-one bundle):
>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>> <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>> xsi:schemaLocation="
>> http://www.osgi.org/xmlns/blueprint/v1.0.0
>> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd">
>>>>
>>>> <service interface="com.pronoia.test.osgi.service.Echo" >
>>>> <service-properties>
>>>> <entry key="instance" value="one" />
>>>> </service-properties>
>>>> <bean class="com.pronoia.test.osgi.service.impl.EchoServiceOne"
>> />
>>>> </service>
>>>>
>>>> </blueprint>
>>>>
>>>> Java RouteBuilder (route-builder bundle):
>>>> public class VerySimpleBuilder extends RouteBuilder {
>>>> Echo blueprintServiceReference;
>>>>
>>>> @Override
>>>> public void configure() throws Exception {
>>>> from("timer://very-simple-builder?period=5000").routeId(
>> "very-simple-route" )
>>>> .setBody( simple( "${exchangeProperty[" +
>> Exchange.TIMER_FIRED_TIME + "]}") )
>>>> .log("Calling Service via Reference: ${body}" )
>>>> .bean(blueprintServiceReference,false)
>>>> .to( "mock://result")
>>>> .log("Finished" );
>>>> }
>>>>
>>>> public Echo getBlueprintServiceReference() {
>>>> return blueprintServiceReference;
>>>> }
>>>>
>>>> public void setBlueprintServiceReference(Echo
>> blueprintServiceReference) {
>>>> this.blueprintServiceReference = blueprintServiceReference;
>>>> }
>>>> }
>>>>
>>>> Blueprint constructing the Camel context (camel-context bundle):
>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>> <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>> xmlns:ext="
>> http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0"
>>>> xsi:schemaLocation="
>>>> http://www.osgi.org/xmlns/blueprint/v1.0.0
>> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
>>>> http://camel.apache.org/schema/blueprint
>> http://camel.apache.org/schema/blueprint/camel-blueprint.xsd"
>>>> <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>
>>>>
>>>> </blueprint>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> http://www.talend.com
>>>
>>
>>
Re: Invoking Dynamic OSGi Blueprint services from a Java RouteBuilder
Posted by Brad Johnson <br...@mediadriver.com>.
https://issues.apache.org/jira/browse/CAMEL-9562
I've opened an issue. I think it is a relatively easy thing to add a
strict mode flag without breaking anyone. You're right that it is easy
enough to make it work right. But if I haven't set something up to work
correctly I don't want the classloader fixing it inadvertently.
I haven't run into this before since for the past two years I've used Camel
blueprint XML exclusively and only used Java for a beans and service
calls. I was venturing into using route builders when I ran into this.
On Tue, Feb 2, 2016 at 10:40 AM, Quinn Stevenson <
quinn@pronoia-solutions.com> wrote:
> Thank You Christian -
>
> Yes - I pointed out that if I used the Bean Component, everything seemed
> to work as I expected.
>
> The problem I have is I use beans in filter blocks as well, and there I
> can’t use the 'to( “bean://<name” )’ construct. I need to keep the
> original message bodies and just filter, and when I use the method(…)
> invocation, it’s hit or miss if it honors dynamic services (i.e. picks-up
> new instances when the implementation is replaced). It’s very sensitive to
> how the bean with the service reference is declared.
>
> I also tried using enrich( “bean://<bean-name>” ) with an aggregation
> strategy to get around this, but it worked the same way as the method( … )
> DSL - it didn’t pickup new service instances when the services were
> replaced.
>
>
>
> > On Feb 2, 2016, at 2:24 AM, Christian Schneider <ch...@die-schneider.net>
> wrote:
> >
> > There is a much simpler way to use an OSGi service with blueprint.
> > Simply use the bean component of camel. It resolves beans against the
> camel registry.
> > When you define your camel context using blueprint then the camel
> registry automatically includes all blueprint beans.
> >
> > So you can do this in java dsl:
> > to("bean:echo-service")
> >
> > It will find the bean with this id in blueprint. In your case it will be
> the service reference.
> >
> > Christian
> >
> > On 26.01.2016 23:11, Quinn Stevenson wrote:
> >> When I use an OSGi Service registered using Blueprint from a Java route
> (built using a Java RouteBuilder), the Camel route isn’t detecting the when
> the service is not available, and it isn’t updating when the service
> implementation changes.
> >>
> >> The simple setup I’m using has a Java interface for the OSGi service in
> one bundle, and implementation of that interface which uses Blueprint to
> register the service in another bundle, and simple RouteBuilder that uses
> the service in a third bundle. The implementation of the service is
> injected into the RouteBuilder using Blueprint, and the Camel context is
> configured in Blueprint in a fourth bundle.
> >>
> >> After all these bundles are installed and started in Karaf, the run and
> the hashCode of service is logged every time the Camel timer fires and
> triggers an exchange. If I stop the bundle that registers the service
> using Blueprint, the route continues to log the same hashCode when it calls
> the OSGi service. I would expect a ServiceUnavailableException after a
> timeout.
> >>
> >> Additionally, when I restart the bundle that registers the service
> object, I continue to get the same hashCode. I would expect to get a new
> hashCode value.
> >>
> >> Am I doing something wrong? Do I need to do something different do get
> the dynamic behavior I’m looking for?
> >>
> >>
> >> The code looks like this:
> >>
> >> Java Interface (service-interface bundle):
> >> public interface Echo {
> >> String execute(String body);
> >> }
> >>
> >> Java Implementation:
> >> public class EchoServiceOne implements Echo {
> >> Logger log = LoggerFactory.getLogger(this.getClass());
> >>
> >> @Override
> >> public String execute(String body) {
> >> log.info( "{}:{} -> execute", this.getClass().getSimpleName(),
> this.hashCode() );
> >> return body;
> >> }
> >> }
> >>
> >>
> >> Blueprint Registering the service (service-one bundle):
> >> <?xml version="1.0" encoding="UTF-8"?>
> >> <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
> >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> >> xsi:schemaLocation="
> http://www.osgi.org/xmlns/blueprint/v1.0.0
> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd">
> >>
> >> <service interface="com.pronoia.test.osgi.service.Echo" >
> >> <service-properties>
> >> <entry key="instance" value="one" />
> >> </service-properties>
> >> <bean class="com.pronoia.test.osgi.service.impl.EchoServiceOne"
> />
> >> </service>
> >>
> >> </blueprint>
> >>
> >> Java RouteBuilder (route-builder bundle):
> >> public class VerySimpleBuilder extends RouteBuilder {
> >> Echo blueprintServiceReference;
> >>
> >> @Override
> >> public void configure() throws Exception {
> >> from("timer://very-simple-builder?period=5000").routeId(
> "very-simple-route" )
> >> .setBody( simple( "${exchangeProperty[" +
> Exchange.TIMER_FIRED_TIME + "]}") )
> >> .log("Calling Service via Reference: ${body}" )
> >> .bean(blueprintServiceReference,false)
> >> .to( "mock://result")
> >> .log("Finished" );
> >> }
> >>
> >> public Echo getBlueprintServiceReference() {
> >> return blueprintServiceReference;
> >> }
> >>
> >> public void setBlueprintServiceReference(Echo
> blueprintServiceReference) {
> >> this.blueprintServiceReference = blueprintServiceReference;
> >> }
> >> }
> >>
> >> Blueprint constructing the Camel context (camel-context bundle):
> >> <?xml version="1.0" encoding="UTF-8"?>
> >> <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
> >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> >> xmlns:ext="
> http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0"
> >> xsi:schemaLocation="
> >> http://www.osgi.org/xmlns/blueprint/v1.0.0
> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
> >> http://camel.apache.org/schema/blueprint
> http://camel.apache.org/schema/blueprint/camel-blueprint.xsd"
> >> <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>
> >>
> >> </blueprint>
> >>
> >>
> >>
> >
> >
> > --
> > Christian Schneider
> > http://www.liquid-reality.de
> >
> > Open Source Architect
> > http://www.talend.com
> >
>
>
Re: Invoking Dynamic OSGi Blueprint services from a Java RouteBuilder
Posted by Brad Johnson <br...@mediadriver.com>.
Good point. I guess I was just running through in my head what I did when
I ran into the problem. There's definitely a classloader difference
depending on how the routes and injection get set up. I have some
speculations about it but that's all. I wish I had more time to chase it
down.
On Fri, Feb 19, 2016 at 11:07 AM, Quinn Stevenson <
quinn@pronoia-solutions.com> wrote:
> 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 <br...@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.johnson@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 <
> >> quinn@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 <
> >>> chris@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 <
> quinn@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 <
> >>> chris@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
> >>>>
> >>>
> >>>
> >>
>
>
Re: Invoking Dynamic OSGi Blueprint services from a Java RouteBuilder
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
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 <br...@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 <br...@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 <
>> quinn@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 <
>>> chris@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 <quinn@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 <
>>> chris@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
>>>>
>>>
>>>
>>
Re: Invoking Dynamic OSGi Blueprint services from a Java RouteBuilder
Posted by Brad Johnson <br...@mediadriver.com>.
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 <br...@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 <
> quinn@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 <
>> chris@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 <quinn@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 <
>> chris@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
>> >
>>
>>
>
Re: Invoking Dynamic OSGi Blueprint services from a Java RouteBuilder
Posted by Brad Johnson <br...@mediadriver.com>.
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 <
quinn@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 <
> chris@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 <
> chris@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
> >
>
>
Re: Invoking Dynamic OSGi Blueprint services from a Java RouteBuilder
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
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>
Re: Invoking Dynamic OSGi Blueprint services from a Java RouteBuilder
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
Brad -
Please feel free to associate the issues - I don’t know exactly how that’s supposed to be done (I’m a little new to the Apache JIRA process).
- Quinn
> On Feb 5, 2016, at 2:10 PM, Brad Johnson <br...@mediadriver.com> wrote:
>
> 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 <quinn@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 <
>> chris@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 <
>> chris@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
>>>
>>
>>
Re: Invoking Dynamic OSGi Blueprint services from a Java RouteBuilder
Posted by Brad Johnson <br...@mediadriver.com>.
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 <quinn@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 <
> chris@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 <
> chris@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
> >
>
>
Re: Invoking Dynamic OSGi Blueprint services from a Java RouteBuilder
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
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>
Re: Invoking Dynamic OSGi Blueprint services from a Java RouteBuilder
Posted by Christian Schneider <ch...@die-schneider.net>.
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>
Re: Invoking Dynamic OSGi Blueprint services from a Java RouteBuilder
Posted by 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
>
Re: Invoking Dynamic OSGi Blueprint services from a Java RouteBuilder
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
> 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
>
Re: Invoking Dynamic OSGi Blueprint services from a Java RouteBuilder
Posted by Christian Schneider <ch...@die-schneider.net>.
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
Re: Invoking Dynamic OSGi Blueprint services from a Java RouteBuilder
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
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.
> On Feb 2, 2016, at 1:37 PM, Christian Schneider <ch...@die-schneider.net> wrote:
>
> I am actually not sure if you have a classloader problem here.
>
> In your original route you use:
>
> .bean(blueprintServiceReference,false)
>
> public void setBlueprintServiceReference(Echo blueprintServiceReference) {
> this.blueprintServiceReference = blueprintServiceReference;
> }
>
> This will simply call the service proxy that was injected by blueprint when the route starts.
> This should pick up changing services according to the rules of blueprint. So I don't think the Camel registry is involved at all in this case. It would
> only be involved when refering to the service via its interface name.
>
> The routebuilder is found by a ref too. So I doubt the class loader is involved there.
>
> Christian
>
> On 02.02.2016 17:40, Quinn Stevenson wrote:
>> Thank You Christian -
>>
>> Yes - I pointed out that if I used the Bean Component, everything seemed to work as I expected.
>>
>> The problem I have is I use beans in filter blocks as well, and there I can’t use the 'to( “bean://<name” )’ construct. I need to keep the original message bodies and just filter, and when I use the method(…) invocation, it’s hit or miss if it honors dynamic services (i.e. picks-up new instances when the implementation is replaced). It’s very sensitive to how the bean with the service reference is declared.
>>
>> I also tried using enrich( “bean://<bean-name>” ) with an aggregation strategy to get around this, but it worked the same way as the method( … ) DSL - it didn’t pickup new service instances when the services were replaced.
>>
>>
>>
>>> On Feb 2, 2016, at 2:24 AM, Christian Schneider <ch...@die-schneider.net> wrote:
>>>
>>> There is a much simpler way to use an OSGi service with blueprint.
>>> Simply use the bean component of camel. It resolves beans against the camel registry.
>>> When you define your camel context using blueprint then the camel registry automatically includes all blueprint beans.
>>>
>>> So you can do this in java dsl:
>>> to("bean:echo-service")
>>>
>>> It will find the bean with this id in blueprint. In your case it will be the service reference.
>>>
>>> Christian
>>>
>>> On 26.01.2016 23:11, Quinn Stevenson wrote:
>>>> When I use an OSGi Service registered using Blueprint from a Java route (built using a Java RouteBuilder), the Camel route isn’t detecting the when the service is not available, and it isn’t updating when the service implementation changes.
>>>>
>>>> The simple setup I’m using has a Java interface for the OSGi service in one bundle, and implementation of that interface which uses Blueprint to register the service in another bundle, and simple RouteBuilder that uses the service in a third bundle. The implementation of the service is injected into the RouteBuilder using Blueprint, and the Camel context is configured in Blueprint in a fourth bundle.
>>>>
>>>> After all these bundles are installed and started in Karaf, the run and the hashCode of service is logged every time the Camel timer fires and triggers an exchange. If I stop the bundle that registers the service using Blueprint, the route continues to log the same hashCode when it calls the OSGi service. I would expect a ServiceUnavailableException after a timeout.
>>>>
>>>> Additionally, when I restart the bundle that registers the service object, I continue to get the same hashCode. I would expect to get a new hashCode value.
>>>>
>>>> Am I doing something wrong? Do I need to do something different do get the dynamic behavior I’m looking for?
>>>>
>>>>
>>>> The code looks like this:
>>>>
>>>> Java Interface (service-interface bundle):
>>>> public interface Echo {
>>>> String execute(String body);
>>>> }
>>>>
>>>> Java Implementation:
>>>> public class EchoServiceOne implements Echo {
>>>> Logger log = LoggerFactory.getLogger(this.getClass());
>>>>
>>>> @Override
>>>> public String execute(String body) {
>>>> log.info( "{}:{} -> execute", this.getClass().getSimpleName(), this.hashCode() );
>>>> return body;
>>>> }
>>>> }
>>>>
>>>>
>>>> Blueprint Registering the service (service-one bundle):
>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>> <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>> xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0 http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd">
>>>>
>>>> <service interface="com.pronoia.test.osgi.service.Echo" >
>>>> <service-properties>
>>>> <entry key="instance" value="one" />
>>>> </service-properties>
>>>> <bean class="com.pronoia.test.osgi.service.impl.EchoServiceOne" />
>>>> </service>
>>>>
>>>> </blueprint>
>>>>
>>>> Java RouteBuilder (route-builder bundle):
>>>> public class VerySimpleBuilder extends RouteBuilder {
>>>> Echo blueprintServiceReference;
>>>>
>>>> @Override
>>>> public void configure() throws Exception {
>>>> from("timer://very-simple-builder?period=5000").routeId( "very-simple-route" )
>>>> .setBody( simple( "${exchangeProperty[" + Exchange.TIMER_FIRED_TIME + "]}") )
>>>> .log("Calling Service via Reference: ${body}" )
>>>> .bean(blueprintServiceReference,false)
>>>> .to( "mock://result")
>>>> .log("Finished" );
>>>> }
>>>>
>>>> public Echo getBlueprintServiceReference() {
>>>> return blueprintServiceReference;
>>>> }
>>>>
>>>> public void setBlueprintServiceReference(Echo blueprintServiceReference) {
>>>> this.blueprintServiceReference = blueprintServiceReference;
>>>> }
>>>> }
>>>>
>>>> Blueprint constructing the Camel context (camel-context bundle):
>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>> <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>> xmlns:ext="http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0"
>>>> xsi:schemaLocation="
>>>> http://www.osgi.org/xmlns/blueprint/v1.0.0 http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
>>>> http://camel.apache.org/schema/blueprint http://camel.apache.org/schema/blueprint/camel-blueprint.xsd"
>>>> <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>
>>>>
>>>> </blueprint>
>>>>
>>>>
>>>>
>>>
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> http://www.talend.com
>>>
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
Re: Invoking Dynamic OSGi Blueprint services from a Java RouteBuilder
Posted by Christian Schneider <ch...@die-schneider.net>.
I am actually not sure if you have a classloader problem here.
In your original route you use:
.bean(blueprintServiceReference,false)
public void setBlueprintServiceReference(Echo blueprintServiceReference) {
this.blueprintServiceReference = blueprintServiceReference;
}
This will simply call the service proxy that was injected by blueprint
when the route starts.
This should pick up changing services according to the rules of
blueprint. So I don't think the Camel registry is involved at all in
this case. It would
only be involved when refering to the service via its interface name.
The routebuilder is found by a ref too. So I doubt the class loader is
involved there.
Christian
On 02.02.2016 17:40, Quinn Stevenson wrote:
> Thank You Christian -
>
> Yes - I pointed out that if I used the Bean Component, everything seemed to work as I expected.
>
> The problem I have is I use beans in filter blocks as well, and there I can’t use the 'to( “bean://<name” )’ construct. I need to keep the original message bodies and just filter, and when I use the method(…) invocation, it’s hit or miss if it honors dynamic services (i.e. picks-up new instances when the implementation is replaced). It’s very sensitive to how the bean with the service reference is declared.
>
> I also tried using enrich( “bean://<bean-name>” ) with an aggregation strategy to get around this, but it worked the same way as the method( … ) DSL - it didn’t pickup new service instances when the services were replaced.
>
>
>
>> On Feb 2, 2016, at 2:24 AM, Christian Schneider <ch...@die-schneider.net> wrote:
>>
>> There is a much simpler way to use an OSGi service with blueprint.
>> Simply use the bean component of camel. It resolves beans against the camel registry.
>> When you define your camel context using blueprint then the camel registry automatically includes all blueprint beans.
>>
>> So you can do this in java dsl:
>> to("bean:echo-service")
>>
>> It will find the bean with this id in blueprint. In your case it will be the service reference.
>>
>> Christian
>>
>> On 26.01.2016 23:11, Quinn Stevenson wrote:
>>> When I use an OSGi Service registered using Blueprint from a Java route (built using a Java RouteBuilder), the Camel route isn’t detecting the when the service is not available, and it isn’t updating when the service implementation changes.
>>>
>>> The simple setup I’m using has a Java interface for the OSGi service in one bundle, and implementation of that interface which uses Blueprint to register the service in another bundle, and simple RouteBuilder that uses the service in a third bundle. The implementation of the service is injected into the RouteBuilder using Blueprint, and the Camel context is configured in Blueprint in a fourth bundle.
>>>
>>> After all these bundles are installed and started in Karaf, the run and the hashCode of service is logged every time the Camel timer fires and triggers an exchange. If I stop the bundle that registers the service using Blueprint, the route continues to log the same hashCode when it calls the OSGi service. I would expect a ServiceUnavailableException after a timeout.
>>>
>>> Additionally, when I restart the bundle that registers the service object, I continue to get the same hashCode. I would expect to get a new hashCode value.
>>>
>>> Am I doing something wrong? Do I need to do something different do get the dynamic behavior I’m looking for?
>>>
>>>
>>> The code looks like this:
>>>
>>> Java Interface (service-interface bundle):
>>> public interface Echo {
>>> String execute(String body);
>>> }
>>>
>>> Java Implementation:
>>> public class EchoServiceOne implements Echo {
>>> Logger log = LoggerFactory.getLogger(this.getClass());
>>>
>>> @Override
>>> public String execute(String body) {
>>> log.info( "{}:{} -> execute", this.getClass().getSimpleName(), this.hashCode() );
>>> return body;
>>> }
>>> }
>>>
>>>
>>> Blueprint Registering the service (service-one bundle):
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>> xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0 http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd">
>>>
>>> <service interface="com.pronoia.test.osgi.service.Echo" >
>>> <service-properties>
>>> <entry key="instance" value="one" />
>>> </service-properties>
>>> <bean class="com.pronoia.test.osgi.service.impl.EchoServiceOne" />
>>> </service>
>>>
>>> </blueprint>
>>>
>>> Java RouteBuilder (route-builder bundle):
>>> public class VerySimpleBuilder extends RouteBuilder {
>>> Echo blueprintServiceReference;
>>>
>>> @Override
>>> public void configure() throws Exception {
>>> from("timer://very-simple-builder?period=5000").routeId( "very-simple-route" )
>>> .setBody( simple( "${exchangeProperty[" + Exchange.TIMER_FIRED_TIME + "]}") )
>>> .log("Calling Service via Reference: ${body}" )
>>> .bean(blueprintServiceReference,false)
>>> .to( "mock://result")
>>> .log("Finished" );
>>> }
>>>
>>> public Echo getBlueprintServiceReference() {
>>> return blueprintServiceReference;
>>> }
>>>
>>> public void setBlueprintServiceReference(Echo blueprintServiceReference) {
>>> this.blueprintServiceReference = blueprintServiceReference;
>>> }
>>> }
>>>
>>> Blueprint constructing the Camel context (camel-context bundle):
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>> xmlns:ext="http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0"
>>> xsi:schemaLocation="
>>> http://www.osgi.org/xmlns/blueprint/v1.0.0 http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
>>> http://camel.apache.org/schema/blueprint http://camel.apache.org/schema/blueprint/camel-blueprint.xsd"
>>> <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>
>>>
>>> </blueprint>
>>>
>>>
>>>
>>
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> http://www.talend.com
>>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Invoking Dynamic OSGi Blueprint services from a Java RouteBuilder
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
Thank You Christian -
Yes - I pointed out that if I used the Bean Component, everything seemed to work as I expected.
The problem I have is I use beans in filter blocks as well, and there I can’t use the 'to( “bean://<name” )’ construct. I need to keep the original message bodies and just filter, and when I use the method(…) invocation, it’s hit or miss if it honors dynamic services (i.e. picks-up new instances when the implementation is replaced). It’s very sensitive to how the bean with the service reference is declared.
I also tried using enrich( “bean://<bean-name>” ) with an aggregation strategy to get around this, but it worked the same way as the method( … ) DSL - it didn’t pickup new service instances when the services were replaced.
> On Feb 2, 2016, at 2:24 AM, Christian Schneider <ch...@die-schneider.net> wrote:
>
> There is a much simpler way to use an OSGi service with blueprint.
> Simply use the bean component of camel. It resolves beans against the camel registry.
> When you define your camel context using blueprint then the camel registry automatically includes all blueprint beans.
>
> So you can do this in java dsl:
> to("bean:echo-service")
>
> It will find the bean with this id in blueprint. In your case it will be the service reference.
>
> Christian
>
> On 26.01.2016 23:11, Quinn Stevenson wrote:
>> When I use an OSGi Service registered using Blueprint from a Java route (built using a Java RouteBuilder), the Camel route isn’t detecting the when the service is not available, and it isn’t updating when the service implementation changes.
>>
>> The simple setup I’m using has a Java interface for the OSGi service in one bundle, and implementation of that interface which uses Blueprint to register the service in another bundle, and simple RouteBuilder that uses the service in a third bundle. The implementation of the service is injected into the RouteBuilder using Blueprint, and the Camel context is configured in Blueprint in a fourth bundle.
>>
>> After all these bundles are installed and started in Karaf, the run and the hashCode of service is logged every time the Camel timer fires and triggers an exchange. If I stop the bundle that registers the service using Blueprint, the route continues to log the same hashCode when it calls the OSGi service. I would expect a ServiceUnavailableException after a timeout.
>>
>> Additionally, when I restart the bundle that registers the service object, I continue to get the same hashCode. I would expect to get a new hashCode value.
>>
>> Am I doing something wrong? Do I need to do something different do get the dynamic behavior I’m looking for?
>>
>>
>> The code looks like this:
>>
>> Java Interface (service-interface bundle):
>> public interface Echo {
>> String execute(String body);
>> }
>>
>> Java Implementation:
>> public class EchoServiceOne implements Echo {
>> Logger log = LoggerFactory.getLogger(this.getClass());
>>
>> @Override
>> public String execute(String body) {
>> log.info( "{}:{} -> execute", this.getClass().getSimpleName(), this.hashCode() );
>> return body;
>> }
>> }
>>
>>
>> Blueprint Registering the service (service-one bundle):
>> <?xml version="1.0" encoding="UTF-8"?>
>> <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0 http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd">
>>
>> <service interface="com.pronoia.test.osgi.service.Echo" >
>> <service-properties>
>> <entry key="instance" value="one" />
>> </service-properties>
>> <bean class="com.pronoia.test.osgi.service.impl.EchoServiceOne" />
>> </service>
>>
>> </blueprint>
>>
>> Java RouteBuilder (route-builder bundle):
>> public class VerySimpleBuilder extends RouteBuilder {
>> Echo blueprintServiceReference;
>>
>> @Override
>> public void configure() throws Exception {
>> from("timer://very-simple-builder?period=5000").routeId( "very-simple-route" )
>> .setBody( simple( "${exchangeProperty[" + Exchange.TIMER_FIRED_TIME + "]}") )
>> .log("Calling Service via Reference: ${body}" )
>> .bean(blueprintServiceReference,false)
>> .to( "mock://result")
>> .log("Finished" );
>> }
>>
>> public Echo getBlueprintServiceReference() {
>> return blueprintServiceReference;
>> }
>>
>> public void setBlueprintServiceReference(Echo blueprintServiceReference) {
>> this.blueprintServiceReference = blueprintServiceReference;
>> }
>> }
>>
>> Blueprint constructing the Camel context (camel-context bundle):
>> <?xml version="1.0" encoding="UTF-8"?>
>> <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xmlns:ext="http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0"
>> xsi:schemaLocation="
>> http://www.osgi.org/xmlns/blueprint/v1.0.0 http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
>> http://camel.apache.org/schema/blueprint http://camel.apache.org/schema/blueprint/camel-blueprint.xsd"
>> <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>
>>
>> </blueprint>
>>
>>
>>
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
Re: Invoking Dynamic OSGi Blueprint services from a Java RouteBuilder
Posted by Christian Schneider <ch...@die-schneider.net>.
I agree about the classloader hacks ... though I am not sure if they are
needed anywhere.
The approach I showed will not suffer from this problem as you directly
tell it to get a bean with an id.
Christian
On 02.02.2016 17:24, Brad Johnson wrote:
> Christian,
>
> Thanks for the constructive thoughts. Theoretically if everything is set
> up correctly then it will find everything in the OSGi registry.
> Unfortunately, when it can't find things in the registry it will look for
> it with the global class loader. That was happening to me. It shouldn't
> have found it because I didn't have something set up right. What I ended up
> with is a non-proxied instance from one bundle running inside an instance
> from another bundle. When I'd switch from the test stub bundle to the
> actual bundle and back it would cause all kinds of havoc because the bundle
> didn't have a reference to an OSGi proxy it had a reference to a concrete
> type and things blew up.
>
> In reality though the classloader cheating should be disallowed or, at the
> very least, disallowable. A simple flag specifying that the OSGi registry
> must be used would result in a hard error. You can imagine that there must
> be more than one instance of Fuse/karaf running out there where non-proxied
> services are running across bundles and developers aren't aware of it. If
> I hadn't been actively swapping bundles which implement the same interface
> I wouldn't have found that it was breaking the bundle encapsulation.
>
> On Tue, Feb 2, 2016 at 3:24 AM, Christian Schneider <chris@die-schneider.net
>> wrote:
>> There is a much simpler way to use an OSGi service with blueprint.
>> Simply use the bean component of camel. It resolves beans against the
>> camel registry.
>> When you define your camel context using blueprint then the camel registry
>> automatically includes all blueprint beans.
>>
>> So you can do this in java dsl:
>> to("bean:echo-service")
>>
>> It will find the bean with this id in blueprint. In your case it will be
>> the service reference.
>>
>> Christian
>>
>>
>> On 26.01.2016 23:11, Quinn Stevenson wrote:
>>
>>> When I use an OSGi Service registered using Blueprint from a Java route
>>> (built using a Java RouteBuilder), the Camel route isn’t detecting the when
>>> the service is not available, and it isn’t updating when the service
>>> implementation changes.
>>>
>>> The simple setup I’m using has a Java interface for the OSGi service in
>>> one bundle, and implementation of that interface which uses Blueprint to
>>> register the service in another bundle, and simple RouteBuilder that uses
>>> the service in a third bundle. The implementation of the service is
>>> injected into the RouteBuilder using Blueprint, and the Camel context is
>>> configured in Blueprint in a fourth bundle.
>>>
>>> After all these bundles are installed and started in Karaf, the run and
>>> the hashCode of service is logged every time the Camel timer fires and
>>> triggers an exchange. If I stop the bundle that registers the service
>>> using Blueprint, the route continues to log the same hashCode when it calls
>>> the OSGi service. I would expect a ServiceUnavailableException after a
>>> timeout.
>>>
>>> Additionally, when I restart the bundle that registers the service
>>> object, I continue to get the same hashCode. I would expect to get a new
>>> hashCode value.
>>>
>>> Am I doing something wrong? Do I need to do something different do get
>>> the dynamic behavior I’m looking for?
>>>
>>>
>>> The code looks like this:
>>>
>>> Java Interface (service-interface bundle):
>>> public interface Echo {
>>> String execute(String body);
>>> }
>>>
>>> Java Implementation:
>>> public class EchoServiceOne implements Echo {
>>> Logger log = LoggerFactory.getLogger(this.getClass());
>>>
>>> @Override
>>> public String execute(String body) {
>>> log.info( "{}:{} -> execute", this.getClass().getSimpleName(),
>>> this.hashCode() );
>>> return body;
>>> }
>>> }
>>>
>>>
>>> Blueprint Registering the service (service-one bundle):
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>> xsi:schemaLocation="
>>> http://www.osgi.org/xmlns/blueprint/v1.0.0
>>> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd">
>>>
>>> <service interface="com.pronoia.test.osgi.service.Echo" >
>>> <service-properties>
>>> <entry key="instance" value="one" />
>>> </service-properties>
>>> <bean class="com.pronoia.test.osgi.service.impl.EchoServiceOne"
>>> />
>>> </service>
>>>
>>> </blueprint>
>>>
>>> Java RouteBuilder (route-builder bundle):
>>> public class VerySimpleBuilder extends RouteBuilder {
>>> Echo blueprintServiceReference;
>>>
>>> @Override
>>> public void configure() throws Exception {
>>> from("timer://very-simple-builder?period=5000").routeId(
>>> "very-simple-route" )
>>> .setBody( simple( "${exchangeProperty[" +
>>> Exchange.TIMER_FIRED_TIME + "]}") )
>>> .log("Calling Service via Reference: ${body}" )
>>> .bean(blueprintServiceReference,false)
>>> .to( "mock://result")
>>> .log("Finished" );
>>> }
>>>
>>> public Echo getBlueprintServiceReference() {
>>> return blueprintServiceReference;
>>> }
>>>
>>> public void setBlueprintServiceReference(Echo
>>> blueprintServiceReference) {
>>> this.blueprintServiceReference = blueprintServiceReference;
>>> }
>>> }
>>>
>>> Blueprint constructing the Camel context (camel-context bundle):
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>> xmlns:ext="
>>> http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0"
>>> xsi:schemaLocation="
>>> http://www.osgi.org/xmlns/blueprint/v1.0.0
>>> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
>>> http://camel.apache.org/schema/blueprint
>>> http://camel.apache.org/schema/blueprint/camel-blueprint.xsd"
>>> <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>
>>>
>>> </blueprint>
>>>
>>>
>>>
>>>
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> http://www.talend.com
>>
>>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Invoking Dynamic OSGi Blueprint services from a Java RouteBuilder
Posted by Brad Johnson <br...@mediadriver.com>.
Christian,
Thanks for the constructive thoughts. Theoretically if everything is set
up correctly then it will find everything in the OSGi registry.
Unfortunately, when it can't find things in the registry it will look for
it with the global class loader. That was happening to me. It shouldn't
have found it because I didn't have something set up right. What I ended up
with is a non-proxied instance from one bundle running inside an instance
from another bundle. When I'd switch from the test stub bundle to the
actual bundle and back it would cause all kinds of havoc because the bundle
didn't have a reference to an OSGi proxy it had a reference to a concrete
type and things blew up.
In reality though the classloader cheating should be disallowed or, at the
very least, disallowable. A simple flag specifying that the OSGi registry
must be used would result in a hard error. You can imagine that there must
be more than one instance of Fuse/karaf running out there where non-proxied
services are running across bundles and developers aren't aware of it. If
I hadn't been actively swapping bundles which implement the same interface
I wouldn't have found that it was breaking the bundle encapsulation.
On Tue, Feb 2, 2016 at 3:24 AM, Christian Schneider <chris@die-schneider.net
> wrote:
> There is a much simpler way to use an OSGi service with blueprint.
> Simply use the bean component of camel. It resolves beans against the
> camel registry.
> When you define your camel context using blueprint then the camel registry
> automatically includes all blueprint beans.
>
> So you can do this in java dsl:
> to("bean:echo-service")
>
> It will find the bean with this id in blueprint. In your case it will be
> the service reference.
>
> Christian
>
>
> On 26.01.2016 23:11, Quinn Stevenson wrote:
>
>> When I use an OSGi Service registered using Blueprint from a Java route
>> (built using a Java RouteBuilder), the Camel route isn’t detecting the when
>> the service is not available, and it isn’t updating when the service
>> implementation changes.
>>
>> The simple setup I’m using has a Java interface for the OSGi service in
>> one bundle, and implementation of that interface which uses Blueprint to
>> register the service in another bundle, and simple RouteBuilder that uses
>> the service in a third bundle. The implementation of the service is
>> injected into the RouteBuilder using Blueprint, and the Camel context is
>> configured in Blueprint in a fourth bundle.
>>
>> After all these bundles are installed and started in Karaf, the run and
>> the hashCode of service is logged every time the Camel timer fires and
>> triggers an exchange. If I stop the bundle that registers the service
>> using Blueprint, the route continues to log the same hashCode when it calls
>> the OSGi service. I would expect a ServiceUnavailableException after a
>> timeout.
>>
>> Additionally, when I restart the bundle that registers the service
>> object, I continue to get the same hashCode. I would expect to get a new
>> hashCode value.
>>
>> Am I doing something wrong? Do I need to do something different do get
>> the dynamic behavior I’m looking for?
>>
>>
>> The code looks like this:
>>
>> Java Interface (service-interface bundle):
>> public interface Echo {
>> String execute(String body);
>> }
>>
>> Java Implementation:
>> public class EchoServiceOne implements Echo {
>> Logger log = LoggerFactory.getLogger(this.getClass());
>>
>> @Override
>> public String execute(String body) {
>> log.info( "{}:{} -> execute", this.getClass().getSimpleName(),
>> this.hashCode() );
>> return body;
>> }
>> }
>>
>>
>> Blueprint Registering the service (service-one bundle):
>> <?xml version="1.0" encoding="UTF-8"?>
>> <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xsi:schemaLocation="
>> http://www.osgi.org/xmlns/blueprint/v1.0.0
>> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd">
>>
>> <service interface="com.pronoia.test.osgi.service.Echo" >
>> <service-properties>
>> <entry key="instance" value="one" />
>> </service-properties>
>> <bean class="com.pronoia.test.osgi.service.impl.EchoServiceOne"
>> />
>> </service>
>>
>> </blueprint>
>>
>> Java RouteBuilder (route-builder bundle):
>> public class VerySimpleBuilder extends RouteBuilder {
>> Echo blueprintServiceReference;
>>
>> @Override
>> public void configure() throws Exception {
>> from("timer://very-simple-builder?period=5000").routeId(
>> "very-simple-route" )
>> .setBody( simple( "${exchangeProperty[" +
>> Exchange.TIMER_FIRED_TIME + "]}") )
>> .log("Calling Service via Reference: ${body}" )
>> .bean(blueprintServiceReference,false)
>> .to( "mock://result")
>> .log("Finished" );
>> }
>>
>> public Echo getBlueprintServiceReference() {
>> return blueprintServiceReference;
>> }
>>
>> public void setBlueprintServiceReference(Echo
>> blueprintServiceReference) {
>> this.blueprintServiceReference = blueprintServiceReference;
>> }
>> }
>>
>> Blueprint constructing the Camel context (camel-context bundle):
>> <?xml version="1.0" encoding="UTF-8"?>
>> <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xmlns:ext="
>> http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0"
>> xsi:schemaLocation="
>> http://www.osgi.org/xmlns/blueprint/v1.0.0
>> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
>> http://camel.apache.org/schema/blueprint
>> http://camel.apache.org/schema/blueprint/camel-blueprint.xsd"
>> <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>
>>
>> </blueprint>
>>
>>
>>
>>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>
Re: Invoking Dynamic OSGi Blueprint services from a Java RouteBuilder
Posted by Christian Schneider <ch...@die-schneider.net>.
There is a much simpler way to use an OSGi service with blueprint.
Simply use the bean component of camel. It resolves beans against the
camel registry.
When you define your camel context using blueprint then the camel
registry automatically includes all blueprint beans.
So you can do this in java dsl:
to("bean:echo-service")
It will find the bean with this id in blueprint. In your case it will be
the service reference.
Christian
On 26.01.2016 23:11, Quinn Stevenson wrote:
> When I use an OSGi Service registered using Blueprint from a Java route (built using a Java RouteBuilder), the Camel route isn’t detecting the when the service is not available, and it isn’t updating when the service implementation changes.
>
> The simple setup I’m using has a Java interface for the OSGi service in one bundle, and implementation of that interface which uses Blueprint to register the service in another bundle, and simple RouteBuilder that uses the service in a third bundle. The implementation of the service is injected into the RouteBuilder using Blueprint, and the Camel context is configured in Blueprint in a fourth bundle.
>
> After all these bundles are installed and started in Karaf, the run and the hashCode of service is logged every time the Camel timer fires and triggers an exchange. If I stop the bundle that registers the service using Blueprint, the route continues to log the same hashCode when it calls the OSGi service. I would expect a ServiceUnavailableException after a timeout.
>
> Additionally, when I restart the bundle that registers the service object, I continue to get the same hashCode. I would expect to get a new hashCode value.
>
> Am I doing something wrong? Do I need to do something different do get the dynamic behavior I’m looking for?
>
>
> The code looks like this:
>
> Java Interface (service-interface bundle):
> public interface Echo {
> String execute(String body);
> }
>
> Java Implementation:
> public class EchoServiceOne implements Echo {
> Logger log = LoggerFactory.getLogger(this.getClass());
>
> @Override
> public String execute(String body) {
> log.info( "{}:{} -> execute", this.getClass().getSimpleName(), this.hashCode() );
> return body;
> }
> }
>
>
> Blueprint Registering the service (service-one bundle):
> <?xml version="1.0" encoding="UTF-8"?>
> <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0 http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd">
>
> <service interface="com.pronoia.test.osgi.service.Echo" >
> <service-properties>
> <entry key="instance" value="one" />
> </service-properties>
> <bean class="com.pronoia.test.osgi.service.impl.EchoServiceOne" />
> </service>
>
> </blueprint>
>
> Java RouteBuilder (route-builder bundle):
> public class VerySimpleBuilder extends RouteBuilder {
> Echo blueprintServiceReference;
>
> @Override
> public void configure() throws Exception {
> from("timer://very-simple-builder?period=5000").routeId( "very-simple-route" )
> .setBody( simple( "${exchangeProperty[" + Exchange.TIMER_FIRED_TIME + "]}") )
> .log("Calling Service via Reference: ${body}" )
> .bean(blueprintServiceReference,false)
> .to( "mock://result")
> .log("Finished" );
> }
>
> public Echo getBlueprintServiceReference() {
> return blueprintServiceReference;
> }
>
> public void setBlueprintServiceReference(Echo blueprintServiceReference) {
> this.blueprintServiceReference = blueprintServiceReference;
> }
> }
>
> Blueprint constructing the Camel context (camel-context bundle):
> <?xml version="1.0" encoding="UTF-8"?>
> <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:ext="http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0"
> xsi:schemaLocation="
> http://www.osgi.org/xmlns/blueprint/v1.0.0 http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
> http://camel.apache.org/schema/blueprint http://camel.apache.org/schema/blueprint/camel-blueprint.xsd"
> <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>
>
> </blueprint>
>
>
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Invoking Dynamic OSGi Blueprint services from a Java
RouteBuilder
Posted by Ranx <br...@mediadriver.com>.
By the way, while I realize this is in there for older JBI constructs this is
what I meant when asking if there is a way that a "strict" flag could be
added.
Perhaps that's a question I should post on the developers forum. Even if by
default the flag was false, being able to set it to true and then have it do
a hard failure if it can't find the class would be preferable for me. And
for most developers I suspect.
--
View this message in context: http://camel.465427.n5.nabble.com/Invoking-Dynamic-OSGi-Blueprint-services-from-a-Java-RouteBuilder-tp5776755p5777109.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Invoking Dynamic OSGi Blueprint services from a Java
RouteBuilder
Posted by Ranx <br...@mediadriver.com>.
I think in my case the problem was with how the package scan is working but
I'm not positive. In the Camel Core OSGi package scanner class there is a
section. If it can find it in OSGi it shrugs, throws up its hands and
resorts to brute force classloading. Instead of getting hard error Camel
was being accommodating and instantiating a non-proxied version of the
class.
public void find(PackageScanFilter test, String packageName,
Set<Class<?>> classes) {
packageName = packageName.replace('.', '/');
// remember the number of classes found so far
int classesSize = classes.size();
// look in osgi bundles
loadImplementationsInBundle(test, packageName, classes);
// if we did not find any new, then fallback to use regular non
bundle class loading
if (classes.size() == classesSize) {
// Using the non-OSGi classloaders as a fallback
// this is necessary when use JBI packaging for servicemix-camel
SU
// so that we get chance to use SU classloader to scan packages
in the SU
log.trace("Cannot find any classes in bundles, not trying
regular classloaders scanning: {}", packageName);
for (ClassLoader classLoader : super.getClassLoaders()) {
if (!isOsgiClassloader(classLoader)) {
find(test, packageName, classLoader, classes);
}
}
}
}
--
View this message in context: http://camel.465427.n5.nabble.com/Invoking-Dynamic-OSGi-Blueprint-services-from-a-Java-RouteBuilder-tp5776755p5777108.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Invoking Dynamic OSGi Blueprint services from a Java RouteBuilder
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
Thanks for the feedback Stephan - you explained a behavior I was seeing when I was putting this together (item 2 in the list below).
I tried doing this with the Blueprint DSL to see what happens, and the route behaves as I’d expect. When I stop the bundle providing the service, I get a ServiceUnavailableException (after the timeout). When I start the bundle providing the service back up, the route will continue to process normally - with a new instance of the service. The only odd part here is the output of the Karaf “list” command - it shows the bundle is in a “Waiting” state (https://issues.apache.org/jira/browse/KARAF-4283 <https://issues.apache.org/jira/browse/KARAF-4283>).
So as near as I can tell, this is a bug. The Blueprint proxies are not being used somehow when they are injected into the RouteBuilder (and ultimately the route). Unless someone has some other idea, I’ll get a sample put together on GitHub and open a JIRA issue for this.
Here’s the Blueprint that works:
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://www.osgi.org/xmlns/blueprint/v1.0.0 http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
http://camel.apache.org/schema/blueprint http://camel.apache.org/schema/blueprint/camel-blueprint.xsd"
>
<bean id="shutdown" class="org.apache.camel.impl.DefaultShutdownStrategy">
<property name="timeout" value="30"/>
</bean>
<reference id="echo-service" interface="com.pronoia.test.osgi.service.Echo" filter="instance=one" timeout="2000" />
<camelContext id="blueprint-context" xmlns="http://camel.apache.org/schema/blueprint">
<route id="blueprint-route">
<from uri="timer://blueprint-route?period=5000"/>
<setBody>
<exchangeProperty>CamelTimerFiredTime</exchangeProperty>
</setBody>
<log message="Calling Service via Reference: ${body}" />
<bean ref="echo-service" />
<log message="Finished"/>
<to uri="mock://result"/>
</route>
</camelContext>
</blueprint>
> On Jan 26, 2016, at 11:52 PM, Siano, Stephan <st...@sap.com> wrote:
>
> Hi,
>
> Sorry for the confusion I may have caused. In your example you are using option 3, which should actually work as you expected.
>
> Best regards
> Stephan
>
> -----Original Message-----
> From: Siano, Stephan [mailto:stephan.siano@sap.com]
> Sent: Mittwoch, 27. Januar 2016 07:40
> To: users@camel.apache.org
> Subject: RE: Invoking Dynamic OSGi Blueprint services from a Java RouteBuilder
>
> Hi,
>
> You have actually two issues. The first Is accessing an OSGi service from a route using Java DSL. Camel lookups are done in a Camel registry. The kind of registry depends on the way you start your camel context, if you are using blueprint to do that, you have a blueprint registry, if you are using Spring you have a spring registry and (AFAIK) if you are using Java DSL you are normally using a JNDI registry. The special thing about the blueprint registry is that it forwards lookups that cannot be resolved from the blueprint context to the OSGi service registry (so you can do lookups with the Camel registry that are doing OSGi service lookups). I don't think that is possible with Java DSL. However these OSGi lookups via the Camel registry are not very dynamic: The service object is retrieved via OSGi API and is pinned in memory (which is not exactly OSGi-like).
>
> The other issue is when you are referencing services with blueprint. The user of this blueprint service reference will not get the service object itself, but a dynamic proxy object, that will remain the same even if you restart the service (it will even delay any calls to the service while it is gone to the time till it is back (or times out)). That way references injected during bundle startup will remain valid even if the underlying service is restarted.
>
> Therefore you can encounter three different behaviours when referencing an OSGi service (however this is registered) in a Camel route:
> 1. trying to reference it via the camel registry with a registry implementation different from the blueprint one doesn't work
> 2. referencing it via the camel registry with the blueprint implementation will work but only unless you restart the service
> 3. referencing the service via blueprint service reference and then referencing the service from the camel route will create a dynamic proxy object (that remains the same over the whole lifecycle but can cope with service restarts just all right).
>
> Best regards
> Stephan
>
> -----Original Message-----
> From: Quinn Stevenson [mailto:quinn@pronoia-solutions.com]
> Sent: Dienstag, 26. Januar 2016 23:11
> To: users@camel.apache.org
> Subject: Invoking Dynamic OSGi Blueprint services from a Java RouteBuilder
>
> When I use an OSGi Service registered using Blueprint from a Java route (built using a Java RouteBuilder), the Camel route isn’t detecting the when the service is not available, and it isn’t updating when the service implementation changes.
>
> The simple setup I’m using has a Java interface for the OSGi service in one bundle, and implementation of that interface which uses Blueprint to register the service in another bundle, and simple RouteBuilder that uses the service in a third bundle. The implementation of the service is injected into the RouteBuilder using Blueprint, and the Camel context is configured in Blueprint in a fourth bundle.
>
> After all these bundles are installed and started in Karaf, the run and the hashCode of service is logged every time the Camel timer fires and triggers an exchange. If I stop the bundle that registers the service using Blueprint, the route continues to log the same hashCode when it calls the OSGi service. I would expect a ServiceUnavailableException after a timeout.
>
> Additionally, when I restart the bundle that registers the service object, I continue to get the same hashCode. I would expect to get a new hashCode value.
>
> Am I doing something wrong? Do I need to do something different do get the dynamic behavior I’m looking for?
>
>
> The code looks like this:
>
> Java Interface (service-interface bundle):
> public interface Echo {
> String execute(String body);
> }
>
> Java Implementation:
> public class EchoServiceOne implements Echo {
> Logger log = LoggerFactory.getLogger(this.getClass());
>
> @Override
> public String execute(String body) {
> log.info( "{}:{} -> execute", this.getClass().getSimpleName(), this.hashCode() );
> return body;
> }
> }
>
>
> Blueprint Registering the service (service-one bundle):
> <?xml version="1.0" encoding="UTF-8"?>
> <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0 http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd">
>
> <service interface="com.pronoia.test.osgi.service.Echo" >
> <service-properties>
> <entry key="instance" value="one" />
> </service-properties>
> <bean class="com.pronoia.test.osgi.service.impl.EchoServiceOne" />
> </service>
>
> </blueprint>
>
> Java RouteBuilder (route-builder bundle):
> public class VerySimpleBuilder extends RouteBuilder {
> Echo blueprintServiceReference;
>
> @Override
> public void configure() throws Exception {
> from("timer://very-simple-builder?period=5000").routeId( "very-simple-route" )
> .setBody( simple( "${exchangeProperty[" + Exchange.TIMER_FIRED_TIME + "]}") )
> .log("Calling Service via Reference: ${body}" )
> .bean(blueprintServiceReference,false)
> .to( "mock://result")
> .log("Finished" );
> }
>
> public Echo getBlueprintServiceReference() {
> return blueprintServiceReference;
> }
>
> public void setBlueprintServiceReference(Echo blueprintServiceReference) {
> this.blueprintServiceReference = blueprintServiceReference;
> }
> }
>
> Blueprint constructing the Camel context (camel-context bundle):
> <?xml version="1.0" encoding="UTF-8"?>
> <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:ext="http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0"
> xsi:schemaLocation="
> http://www.osgi.org/xmlns/blueprint/v1.0.0 http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
> http://camel.apache.org/schema/blueprint http://camel.apache.org/schema/blueprint/camel-blueprint.xsd"
>>
>
> <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>
>
> </blueprint>
>
>
RE: Invoking Dynamic OSGi Blueprint services from a Java RouteBuilder
Posted by "Siano, Stephan" <st...@sap.com>.
Hi,
Sorry for the confusion I may have caused. In your example you are using option 3, which should actually work as you expected.
Best regards
Stephan
-----Original Message-----
From: Siano, Stephan [mailto:stephan.siano@sap.com]
Sent: Mittwoch, 27. Januar 2016 07:40
To: users@camel.apache.org
Subject: RE: Invoking Dynamic OSGi Blueprint services from a Java RouteBuilder
Hi,
You have actually two issues. The first Is accessing an OSGi service from a route using Java DSL. Camel lookups are done in a Camel registry. The kind of registry depends on the way you start your camel context, if you are using blueprint to do that, you have a blueprint registry, if you are using Spring you have a spring registry and (AFAIK) if you are using Java DSL you are normally using a JNDI registry. The special thing about the blueprint registry is that it forwards lookups that cannot be resolved from the blueprint context to the OSGi service registry (so you can do lookups with the Camel registry that are doing OSGi service lookups). I don't think that is possible with Java DSL. However these OSGi lookups via the Camel registry are not very dynamic: The service object is retrieved via OSGi API and is pinned in memory (which is not exactly OSGi-like).
The other issue is when you are referencing services with blueprint. The user of this blueprint service reference will not get the service object itself, but a dynamic proxy object, that will remain the same even if you restart the service (it will even delay any calls to the service while it is gone to the time till it is back (or times out)). That way references injected during bundle startup will remain valid even if the underlying service is restarted.
Therefore you can encounter three different behaviours when referencing an OSGi service (however this is registered) in a Camel route:
1. trying to reference it via the camel registry with a registry implementation different from the blueprint one doesn't work
2. referencing it via the camel registry with the blueprint implementation will work but only unless you restart the service
3. referencing the service via blueprint service reference and then referencing the service from the camel route will create a dynamic proxy object (that remains the same over the whole lifecycle but can cope with service restarts just all right).
Best regards
Stephan
-----Original Message-----
From: Quinn Stevenson [mailto:quinn@pronoia-solutions.com]
Sent: Dienstag, 26. Januar 2016 23:11
To: users@camel.apache.org
Subject: Invoking Dynamic OSGi Blueprint services from a Java RouteBuilder
When I use an OSGi Service registered using Blueprint from a Java route (built using a Java RouteBuilder), the Camel route isn’t detecting the when the service is not available, and it isn’t updating when the service implementation changes.
The simple setup I’m using has a Java interface for the OSGi service in one bundle, and implementation of that interface which uses Blueprint to register the service in another bundle, and simple RouteBuilder that uses the service in a third bundle. The implementation of the service is injected into the RouteBuilder using Blueprint, and the Camel context is configured in Blueprint in a fourth bundle.
After all these bundles are installed and started in Karaf, the run and the hashCode of service is logged every time the Camel timer fires and triggers an exchange. If I stop the bundle that registers the service using Blueprint, the route continues to log the same hashCode when it calls the OSGi service. I would expect a ServiceUnavailableException after a timeout.
Additionally, when I restart the bundle that registers the service object, I continue to get the same hashCode. I would expect to get a new hashCode value.
Am I doing something wrong? Do I need to do something different do get the dynamic behavior I’m looking for?
The code looks like this:
Java Interface (service-interface bundle):
public interface Echo {
String execute(String body);
}
Java Implementation:
public class EchoServiceOne implements Echo {
Logger log = LoggerFactory.getLogger(this.getClass());
@Override
public String execute(String body) {
log.info( "{}:{} -> execute", this.getClass().getSimpleName(), this.hashCode() );
return body;
}
}
Blueprint Registering the service (service-one bundle):
<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0 http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd">
<service interface="com.pronoia.test.osgi.service.Echo" >
<service-properties>
<entry key="instance" value="one" />
</service-properties>
<bean class="com.pronoia.test.osgi.service.impl.EchoServiceOne" />
</service>
</blueprint>
Java RouteBuilder (route-builder bundle):
public class VerySimpleBuilder extends RouteBuilder {
Echo blueprintServiceReference;
@Override
public void configure() throws Exception {
from("timer://very-simple-builder?period=5000").routeId( "very-simple-route" )
.setBody( simple( "${exchangeProperty[" + Exchange.TIMER_FIRED_TIME + "]}") )
.log("Calling Service via Reference: ${body}" )
.bean(blueprintServiceReference,false)
.to( "mock://result")
.log("Finished" );
}
public Echo getBlueprintServiceReference() {
return blueprintServiceReference;
}
public void setBlueprintServiceReference(Echo blueprintServiceReference) {
this.blueprintServiceReference = blueprintServiceReference;
}
}
Blueprint constructing the Camel context (camel-context bundle):
<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ext="http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0"
xsi:schemaLocation="
http://www.osgi.org/xmlns/blueprint/v1.0.0 http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
http://camel.apache.org/schema/blueprint http://camel.apache.org/schema/blueprint/camel-blueprint.xsd"
>
<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>
</blueprint>
RE: Invoking Dynamic OSGi Blueprint services from a Java RouteBuilder
Posted by "Siano, Stephan" <st...@sap.com>.
Hi,
You have actually two issues. The first Is accessing an OSGi service from a route using Java DSL. Camel lookups are done in a Camel registry. The kind of registry depends on the way you start your camel context, if you are using blueprint to do that, you have a blueprint registry, if you are using Spring you have a spring registry and (AFAIK) if you are using Java DSL you are normally using a JNDI registry. The special thing about the blueprint registry is that it forwards lookups that cannot be resolved from the blueprint context to the OSGi service registry (so you can do lookups with the Camel registry that are doing OSGi service lookups). I don't think that is possible with Java DSL. However these OSGi lookups via the Camel registry are not very dynamic: The service object is retrieved via OSGi API and is pinned in memory (which is not exactly OSGi-like).
The other issue is when you are referencing services with blueprint. The user of this blueprint service reference will not get the service object itself, but a dynamic proxy object, that will remain the same even if you restart the service (it will even delay any calls to the service while it is gone to the time till it is back (or times out)). That way references injected during bundle startup will remain valid even if the underlying service is restarted.
Therefore you can encounter three different behaviours when referencing an OSGi service (however this is registered) in a Camel route:
1. trying to reference it via the camel registry with a registry implementation different from the blueprint one doesn't work
2. referencing it via the camel registry with the blueprint implementation will work but only unless you restart the service
3. referencing the service via blueprint service reference and then referencing the service from the camel route will create a dynamic proxy object (that remains the same over the whole lifecycle but can cope with service restarts just all right).
Best regards
Stephan
-----Original Message-----
From: Quinn Stevenson [mailto:quinn@pronoia-solutions.com]
Sent: Dienstag, 26. Januar 2016 23:11
To: users@camel.apache.org
Subject: Invoking Dynamic OSGi Blueprint services from a Java RouteBuilder
When I use an OSGi Service registered using Blueprint from a Java route (built using a Java RouteBuilder), the Camel route isn’t detecting the when the service is not available, and it isn’t updating when the service implementation changes.
The simple setup I’m using has a Java interface for the OSGi service in one bundle, and implementation of that interface which uses Blueprint to register the service in another bundle, and simple RouteBuilder that uses the service in a third bundle. The implementation of the service is injected into the RouteBuilder using Blueprint, and the Camel context is configured in Blueprint in a fourth bundle.
After all these bundles are installed and started in Karaf, the run and the hashCode of service is logged every time the Camel timer fires and triggers an exchange. If I stop the bundle that registers the service using Blueprint, the route continues to log the same hashCode when it calls the OSGi service. I would expect a ServiceUnavailableException after a timeout.
Additionally, when I restart the bundle that registers the service object, I continue to get the same hashCode. I would expect to get a new hashCode value.
Am I doing something wrong? Do I need to do something different do get the dynamic behavior I’m looking for?
The code looks like this:
Java Interface (service-interface bundle):
public interface Echo {
String execute(String body);
}
Java Implementation:
public class EchoServiceOne implements Echo {
Logger log = LoggerFactory.getLogger(this.getClass());
@Override
public String execute(String body) {
log.info( "{}:{} -> execute", this.getClass().getSimpleName(), this.hashCode() );
return body;
}
}
Blueprint Registering the service (service-one bundle):
<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0 http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd">
<service interface="com.pronoia.test.osgi.service.Echo" >
<service-properties>
<entry key="instance" value="one" />
</service-properties>
<bean class="com.pronoia.test.osgi.service.impl.EchoServiceOne" />
</service>
</blueprint>
Java RouteBuilder (route-builder bundle):
public class VerySimpleBuilder extends RouteBuilder {
Echo blueprintServiceReference;
@Override
public void configure() throws Exception {
from("timer://very-simple-builder?period=5000").routeId( "very-simple-route" )
.setBody( simple( "${exchangeProperty[" + Exchange.TIMER_FIRED_TIME + "]}") )
.log("Calling Service via Reference: ${body}" )
.bean(blueprintServiceReference,false)
.to( "mock://result")
.log("Finished" );
}
public Echo getBlueprintServiceReference() {
return blueprintServiceReference;
}
public void setBlueprintServiceReference(Echo blueprintServiceReference) {
this.blueprintServiceReference = blueprintServiceReference;
}
}
Blueprint constructing the Camel context (camel-context bundle):
<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ext="http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0"
xsi:schemaLocation="
http://www.osgi.org/xmlns/blueprint/v1.0.0 http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
http://camel.apache.org/schema/blueprint http://camel.apache.org/schema/blueprint/camel-blueprint.xsd"
>
<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>
</blueprint>