Re: Camel OSGi services component
Hi guys, I like the idea with URIs like that direct-vm:/endpoint/topicName/subTopicName/subSubTopicName?params. So as Guillaume said the recipient list can be retrieved using something like xpath or even ant-style expressions recipientList(directVm(/endpoint/*/subTopicName/subSubTopicName)) - topic can be anything, but subtopics should match recipientList(directVm(/endpoint/**)) - topic and subtopics can be anything recipientList(directVm(/endpoint/topicName/**)) - topic should match, but subtopics should not recipientList(directVm(/endpoint/topicName/*/subSubTopicName)) - the second subtopic should match, the first one - should not. I also suppose that this approach is less error prone when multiple direct-vm consumers are involved. Regards, Sergey Yes, or something even more flexible such as to(direct-vm:/parent/child) and for the expression, a simple xpath like: from(foo:bar).recipientList(directVm(/parent/*)) or /parent//* Just a thought though, not sure if that's really needed. On Sat, Jun 23, 2012 at 9:18 AM, Claus Ibsen claus.ib...@gmail.com wrote: On Fri, Jun 22, 2012 at 10:41 PM, Sergey Zhemzhitsky szh.s...@gmail.com wrote: Hello Guillaume, I suppose static method to retrieve consumers that can be filtered by a custom expression will be quite enough. Yeah that may be a good idea and fairly easy to implement. The regular direct component could in theory also support this, but I guess direct-vm makes the most sense only, as its cross CamelContext communication. The filter expression could also be defined in the uri, if we want to consider that, though the foo name would then become a dummy? Or would it be to confusing if the name is a filter itself .to(direct-vm:dummy?filter=someFilterStuffHere) .to(direct-vm:someFilterStuffHere) Regards, Sergey On Fri, Jun 22, 2012 at 6:33 AM, Sergey Zhemzhitsky szh.s...@gmail.com wrote: Hello, guys, I agree that if the camel-core could be enhanced to achieve easy cross-context communication in the single JVM it would be fine. Claus committed the direct-vm component recently which is part of 2.10: http://camel.apache.org/direct-vm.html In that case I would not tire the core to OSGi anyhow to be really environment-independent. I suppose that camel context could be published into the JNDI to be retrieved at some time lately to discover consuming endpoints. Thus we can achieve the similar behavior in different environments and from(foo:bar).recipientList(osgiServices(myldapfilter)) would become from(foo:bar).recipientList(vm(myfilter)) Atm, the direct-vm queues are not really accessible afaik, so we may need to enhance the direct-vm slightly to allow retrieving the set of registered consumers (adding a static getRegisteredConsumers on the component should be sufficient). Those are mapped by the path component of the consumer uris, so it already provides some kinda of tree based structure. If that's sufficient, we would just need a simple expression that would filter them based on some regular expression maybe. Regards, Sergey Agree, I think that enhancing the existing could achieve this. Regards JB On 06/21/2012 08:51 AM, Guillaume Nodet wrote: That's really my main goal. If we fit into what already exists more, we'll be able to better leverage everything. On Thu, Jun 21, 2012 at 8:48 AM, Christian Schneider ch...@die-schneider.net wrote: +1 I like that aproach. It would make the OSGi services component a lot simpler. from(foo:bar).recipientList(osgiServices(myldapfilter)) I guess we can use a similar aproach to achieve load balancing. Not sure if the example below already would work but I am sure we could make it work this way or similar: from(foo:bar).loadbalance().roundRobin().recepientList(osgiServices(myldapfilter)) Christian Am 21.06.2012 08:27, schrieb Guillaume Nodet: Yeah, and I agree leveraging OSGi services for that is a good idea. That's not really what I'm concerned about. The goal is to have a way to multicast a message to a set of endpoint which will be discovered at runtime, and that's not really OSGi specific (though the fact that OSGi has a service registry make that use case very relevant). I'd like to reuse what camel-core provides for that instead of going around and implementing a brand new component. The dynamic recipient list works with an Expression which returns a list of endpoints (either Endpoint or string uris), so why not writing such an expression ? This expression could easily use a ServiceTracker internally to track changes on services and the expression itself could be an osgi filter... from(foo:bar).recipientList(osgiServices(myldapfilter)) We could even maybe make use of the CamelContext internal registry which can do some type of discovery (though the osgi implementation is lacking a lot of stuff). A simple one would at least be some kind of regular expression
Re: Camel OSGi services component
On Fri, Jun 22, 2012 at 10:41 PM, Sergey Zhemzhitsky szh.s...@gmail.com wrote: Hello Guillaume, I suppose static method to retrieve consumers that can be filtered by a custom expression will be quite enough. Yeah that may be a good idea and fairly easy to implement. The regular direct component could in theory also support this, but I guess direct-vm makes the most sense only, as its cross CamelContext communication. The filter expression could also be defined in the uri, if we want to consider that, though the foo name would then become a dummy? Or would it be to confusing if the name is a filter itself .to(direct-vm:dummy?filter=someFilterStuffHere) .to(direct-vm:someFilterStuffHere) Regards, Sergey On Fri, Jun 22, 2012 at 6:33 AM, Sergey Zhemzhitsky szh.s...@gmail.com wrote: Hello, guys, I agree that if the camel-core could be enhanced to achieve easy cross-context communication in the single JVM it would be fine. Claus committed the direct-vm component recently which is part of 2.10: http://camel.apache.org/direct-vm.html In that case I would not tire the core to OSGi anyhow to be really environment-independent. I suppose that camel context could be published into the JNDI to be retrieved at some time lately to discover consuming endpoints. Thus we can achieve the similar behavior in different environments and from(foo:bar).recipientList(osgiServices(myldapfilter)) would become from(foo:bar).recipientList(vm(myfilter)) Atm, the direct-vm queues are not really accessible afaik, so we may need to enhance the direct-vm slightly to allow retrieving the set of registered consumers (adding a static getRegisteredConsumers on the component should be sufficient). Those are mapped by the path component of the consumer uris, so it already provides some kinda of tree based structure. If that's sufficient, we would just need a simple expression that would filter them based on some regular expression maybe. Regards, Sergey Agree, I think that enhancing the existing could achieve this. Regards JB On 06/21/2012 08:51 AM, Guillaume Nodet wrote: That's really my main goal. If we fit into what already exists more, we'll be able to better leverage everything. On Thu, Jun 21, 2012 at 8:48 AM, Christian Schneider ch...@die-schneider.net wrote: +1 I like that aproach. It would make the OSGi services component a lot simpler. from(foo:bar).recipientList(osgiServices(myldapfilter)) I guess we can use a similar aproach to achieve load balancing. Not sure if the example below already would work but I am sure we could make it work this way or similar: from(foo:bar).loadbalance().roundRobin().recepientList(osgiServices(myldapfilter)) Christian Am 21.06.2012 08:27, schrieb Guillaume Nodet: Yeah, and I agree leveraging OSGi services for that is a good idea. That's not really what I'm concerned about. The goal is to have a way to multicast a message to a set of endpoint which will be discovered at runtime, and that's not really OSGi specific (though the fact that OSGi has a service registry make that use case very relevant). I'd like to reuse what camel-core provides for that instead of going around and implementing a brand new component. The dynamic recipient list works with an Expression which returns a list of endpoints (either Endpoint or string uris), so why not writing such an expression ? This expression could easily use a ServiceTracker internally to track changes on services and the expression itself could be an osgi filter... from(foo:bar).recipientList(osgiServices(myldapfilter)) We could even maybe make use of the CamelContext internal registry which can do some type of discovery (though the osgi implementation is lacking a lot of stuff). A simple one would at least be some kind of regular expression that would match some endpoints. We may need something slightly more specific for vm:// and direct-vm:// which can be used for cross-camelContext exchanges. And sorry if I seem a bit reluctant, I'm just trying to make things fit more cleanly in camel, and improve camel core where it needs rather than implementing a new component. It just seems that your requirements are not really osgi specific and could be made slightly mode generic. On Thu, Jun 21, 2012 at 7:41 AM, Sergey Zhemzhitskyszh.s...@gmail.com wrote: Hi Guillaume, Of course if there is more convenient way to communicate between bundles there is no need in the component. On the moment of development of this component there were multiple ways to do that, for instance: 1. jms component which is rather heavyweight to do inter-bundle communication in the same jvm. 2. vm component which is asynchronous and does not support transactions 3. nmr component which can be used in synchronous mode, but does not support pub-sub, although it does not prevent user from registering multiple consuming endpoints with the same
Re: Camel OSGi services component
Yes, or something even more flexible such as to(direct-vm:/parent/child) and for the expression, a simple xpath like: from(foo:bar).recipientList(directVm(/parent/*)) or /parent//* Just a thought though, not sure if that's really needed. On Sat, Jun 23, 2012 at 9:18 AM, Claus Ibsen claus.ib...@gmail.com wrote: On Fri, Jun 22, 2012 at 10:41 PM, Sergey Zhemzhitsky szh.s...@gmail.com wrote: Hello Guillaume, I suppose static method to retrieve consumers that can be filtered by a custom expression will be quite enough. Yeah that may be a good idea and fairly easy to implement. The regular direct component could in theory also support this, but I guess direct-vm makes the most sense only, as its cross CamelContext communication. The filter expression could also be defined in the uri, if we want to consider that, though the foo name would then become a dummy? Or would it be to confusing if the name is a filter itself .to(direct-vm:dummy?filter=someFilterStuffHere) .to(direct-vm:someFilterStuffHere) Regards, Sergey On Fri, Jun 22, 2012 at 6:33 AM, Sergey Zhemzhitsky szh.s...@gmail.com wrote: Hello, guys, I agree that if the camel-core could be enhanced to achieve easy cross-context communication in the single JVM it would be fine. Claus committed the direct-vm component recently which is part of 2.10: http://camel.apache.org/direct-vm.html In that case I would not tire the core to OSGi anyhow to be really environment-independent. I suppose that camel context could be published into the JNDI to be retrieved at some time lately to discover consuming endpoints. Thus we can achieve the similar behavior in different environments and from(foo:bar).recipientList(osgiServices(myldapfilter)) would become from(foo:bar).recipientList(vm(myfilter)) Atm, the direct-vm queues are not really accessible afaik, so we may need to enhance the direct-vm slightly to allow retrieving the set of registered consumers (adding a static getRegisteredConsumers on the component should be sufficient). Those are mapped by the path component of the consumer uris, so it already provides some kinda of tree based structure. If that's sufficient, we would just need a simple expression that would filter them based on some regular expression maybe. Regards, Sergey Agree, I think that enhancing the existing could achieve this. Regards JB On 06/21/2012 08:51 AM, Guillaume Nodet wrote: That's really my main goal. If we fit into what already exists more, we'll be able to better leverage everything. On Thu, Jun 21, 2012 at 8:48 AM, Christian Schneider ch...@die-schneider.net wrote: +1 I like that aproach. It would make the OSGi services component a lot simpler. from(foo:bar).recipientList(osgiServices(myldapfilter)) I guess we can use a similar aproach to achieve load balancing. Not sure if the example below already would work but I am sure we could make it work this way or similar: from(foo:bar).loadbalance().roundRobin().recepientList(osgiServices(myldapfilter)) Christian Am 21.06.2012 08:27, schrieb Guillaume Nodet: Yeah, and I agree leveraging OSGi services for that is a good idea. That's not really what I'm concerned about. The goal is to have a way to multicast a message to a set of endpoint which will be discovered at runtime, and that's not really OSGi specific (though the fact that OSGi has a service registry make that use case very relevant). I'd like to reuse what camel-core provides for that instead of going around and implementing a brand new component. The dynamic recipient list works with an Expression which returns a list of endpoints (either Endpoint or string uris), so why not writing such an expression ? This expression could easily use a ServiceTracker internally to track changes on services and the expression itself could be an osgi filter... from(foo:bar).recipientList(osgiServices(myldapfilter)) We could even maybe make use of the CamelContext internal registry which can do some type of discovery (though the osgi implementation is lacking a lot of stuff). A simple one would at least be some kind of regular expression that would match some endpoints. We may need something slightly more specific for vm:// and direct-vm:// which can be used for cross-camelContext exchanges. And sorry if I seem a bit reluctant, I'm just trying to make things fit more cleanly in camel, and improve camel core where it needs rather than implementing a new component. It just seems that your requirements are not really osgi specific and could be made slightly mode generic. On Thu, Jun 21, 2012 at 7:41 AM, Sergey Zhemzhitskyszh.s...@gmail.com wrote: Hi Guillaume, Of course if there is more convenient way to communicate between bundles there is no need in the component. On the moment of development of this component there were multiple ways to do that, for instance: 1. jms component
Re: Camel OSGi services component
On Fri, Jun 22, 2012 at 6:33 AM, Sergey Zhemzhitsky szh.s...@gmail.com wrote: Hello, guys, I agree that if the camel-core could be enhanced to achieve easy cross-context communication in the single JVM it would be fine. Claus committed the direct-vm component recently which is part of 2.10: http://camel.apache.org/direct-vm.html In that case I would not tire the core to OSGi anyhow to be really environment-independent. I suppose that camel context could be published into the JNDI to be retrieved at some time lately to discover consuming endpoints. Thus we can achieve the similar behavior in different environments and from(foo:bar).recipientList(osgiServices(myldapfilter)) would become from(foo:bar).recipientList(vm(myfilter)) Atm, the direct-vm queues are not really accessible afaik, so we may need to enhance the direct-vm slightly to allow retrieving the set of registered consumers (adding a static getRegisteredConsumers on the component should be sufficient). Those are mapped by the path component of the consumer uris, so it already provides some kinda of tree based structure. If that's sufficient, we would just need a simple expression that would filter them based on some regular expression maybe. Regards, Sergey Agree, I think that enhancing the existing could achieve this. Regards JB On 06/21/2012 08:51 AM, Guillaume Nodet wrote: That's really my main goal. If we fit into what already exists more, we'll be able to better leverage everything. On Thu, Jun 21, 2012 at 8:48 AM, Christian Schneider ch...@die-schneider.net wrote: +1 I like that aproach. It would make the OSGi services component a lot simpler. from(foo:bar).recipientList(osgiServices(myldapfilter)) I guess we can use a similar aproach to achieve load balancing. Not sure if the example below already would work but I am sure we could make it work this way or similar: from(foo:bar).loadbalance().roundRobin().recepientList(osgiServices(myldapfilter)) Christian Am 21.06.2012 08:27, schrieb Guillaume Nodet: Yeah, and I agree leveraging OSGi services for that is a good idea. That's not really what I'm concerned about. The goal is to have a way to multicast a message to a set of endpoint which will be discovered at runtime, and that's not really OSGi specific (though the fact that OSGi has a service registry make that use case very relevant). I'd like to reuse what camel-core provides for that instead of going around and implementing a brand new component. The dynamic recipient list works with an Expression which returns a list of endpoints (either Endpoint or string uris), so why not writing such an expression ? This expression could easily use a ServiceTracker internally to track changes on services and the expression itself could be an osgi filter... from(foo:bar).recipientList(osgiServices(myldapfilter)) We could even maybe make use of the CamelContext internal registry which can do some type of discovery (though the osgi implementation is lacking a lot of stuff). A simple one would at least be some kind of regular expression that would match some endpoints. We may need something slightly more specific for vm:// and direct-vm:// which can be used for cross-camelContext exchanges. And sorry if I seem a bit reluctant, I'm just trying to make things fit more cleanly in camel, and improve camel core where it needs rather than implementing a new component. It just seems that your requirements are not really osgi specific and could be made slightly mode generic. On Thu, Jun 21, 2012 at 7:41 AM, Sergey Zhemzhitskyszh.s...@gmail.com wrote: Hi Guillaume, Of course if there is more convenient way to communicate between bundles there is no need in the component. On the moment of development of this component there were multiple ways to do that, for instance: 1. jms component which is rather heavyweight to do inter-bundle communication in the same jvm. 2. vm component which is asynchronous and does not support transactions 3. nmr component which can be used in synchronous mode, but does not support pub-sub, although it does not prevent user from registering multiple consuming endpoints with the same name, so the messages are sent only to the first registered nmr-consumer. The new direct-vm component solves the issue with transactions (like synchronous nmr does) but it does not support pub-sub too. To use a dynamic recipient list it's necessary to have some kind of custom code that will resolve addresses of recipients at runtime. In such a case syncronous nmr can be used as well. The benefit of OSGi services is that this is a standard functionality of OSGi runtime and even OSGi api predisposed to work with an array of them. Furthermore you will get all the benefits of OSGi services, i.e. dynamism, priorities, etc. It would be nice if direct-vm allowed to configure pub-sub with all the options of multicast
Re: Camel OSGi services component
Hello Guillaume, I suppose static method to retrieve consumers that can be filtered by a custom expression will be quite enough. Regards, Sergey On Fri, Jun 22, 2012 at 6:33 AM, Sergey Zhemzhitsky szh.s...@gmail.com wrote: Hello, guys, I agree that if the camel-core could be enhanced to achieve easy cross-context communication in the single JVM it would be fine. Claus committed the direct-vm component recently which is part of 2.10: http://camel.apache.org/direct-vm.html In that case I would not tire the core to OSGi anyhow to be really environment-independent. I suppose that camel context could be published into the JNDI to be retrieved at some time lately to discover consuming endpoints. Thus we can achieve the similar behavior in different environments and from(foo:bar).recipientList(osgiServices(myldapfilter)) would become from(foo:bar).recipientList(vm(myfilter)) Atm, the direct-vm queues are not really accessible afaik, so we may need to enhance the direct-vm slightly to allow retrieving the set of registered consumers (adding a static getRegisteredConsumers on the component should be sufficient). Those are mapped by the path component of the consumer uris, so it already provides some kinda of tree based structure. If that's sufficient, we would just need a simple expression that would filter them based on some regular expression maybe. Regards, Sergey Agree, I think that enhancing the existing could achieve this. Regards JB On 06/21/2012 08:51 AM, Guillaume Nodet wrote: That's really my main goal. If we fit into what already exists more, we'll be able to better leverage everything. On Thu, Jun 21, 2012 at 8:48 AM, Christian Schneider ch...@die-schneider.net wrote: +1 I like that aproach. It would make the OSGi services component a lot simpler. from(foo:bar).recipientList(osgiServices(myldapfilter)) I guess we can use a similar aproach to achieve load balancing. Not sure if the example below already would work but I am sure we could make it work this way or similar: from(foo:bar).loadbalance().roundRobin().recepientList(osgiServices(myldapfilter)) Christian Am 21.06.2012 08:27, schrieb Guillaume Nodet: Yeah, and I agree leveraging OSGi services for that is a good idea. That's not really what I'm concerned about. The goal is to have a way to multicast a message to a set of endpoint which will be discovered at runtime, and that's not really OSGi specific (though the fact that OSGi has a service registry make that use case very relevant). I'd like to reuse what camel-core provides for that instead of going around and implementing a brand new component. The dynamic recipient list works with an Expression which returns a list of endpoints (either Endpoint or string uris), so why not writing such an expression ? This expression could easily use a ServiceTracker internally to track changes on services and the expression itself could be an osgi filter... from(foo:bar).recipientList(osgiServices(myldapfilter)) We could even maybe make use of the CamelContext internal registry which can do some type of discovery (though the osgi implementation is lacking a lot of stuff). A simple one would at least be some kind of regular expression that would match some endpoints. We may need something slightly more specific for vm:// and direct-vm:// which can be used for cross-camelContext exchanges. And sorry if I seem a bit reluctant, I'm just trying to make things fit more cleanly in camel, and improve camel core where it needs rather than implementing a new component. It just seems that your requirements are not really osgi specific and could be made slightly mode generic. On Thu, Jun 21, 2012 at 7:41 AM, Sergey Zhemzhitskyszh.s...@gmail.com wrote: Hi Guillaume, Of course if there is more convenient way to communicate between bundles there is no need in the component. On the moment of development of this component there were multiple ways to do that, for instance: 1. jms component which is rather heavyweight to do inter-bundle communication in the same jvm. 2. vm component which is asynchronous and does not support transactions 3. nmr component which can be used in synchronous mode, but does not support pub-sub, although it does not prevent user from registering multiple consuming endpoints with the same name, so the messages are sent only to the first registered nmr-consumer. The new direct-vm component solves the issue with transactions (like synchronous nmr does) but it does not support pub-sub too. To use a dynamic recipient list it's necessary to have some kind of custom code that will resolve addresses of recipients at runtime. In such a case syncronous nmr can be used as well. The benefit of OSGi services is that this is a standard functionality of OSGi runtime and even OSGi api predisposed to work with an array of them. Furthermore you will get all
Re: Camel OSGi services component
Yeah, and I agree leveraging OSGi services for that is a good idea. That's not really what I'm concerned about. The goal is to have a way to multicast a message to a set of endpoint which will be discovered at runtime, and that's not really OSGi specific (though the fact that OSGi has a service registry make that use case very relevant). I'd like to reuse what camel-core provides for that instead of going around and implementing a brand new component. The dynamic recipient list works with an Expression which returns a list of endpoints (either Endpoint or string uris), so why not writing such an expression ? This expression could easily use a ServiceTracker internally to track changes on services and the expression itself could be an osgi filter... from(foo:bar).recipientList(osgiServices(myldapfilter)) We could even maybe make use of the CamelContext internal registry which can do some type of discovery (though the osgi implementation is lacking a lot of stuff). A simple one would at least be some kind of regular expression that would match some endpoints. We may need something slightly more specific for vm:// and direct-vm:// which can be used for cross-camelContext exchanges. And sorry if I seem a bit reluctant, I'm just trying to make things fit more cleanly in camel, and improve camel core where it needs rather than implementing a new component. It just seems that your requirements are not really osgi specific and could be made slightly mode generic. On Thu, Jun 21, 2012 at 7:41 AM, Sergey Zhemzhitsky szh.s...@gmail.com wrote: Hi Guillaume, Of course if there is more convenient way to communicate between bundles there is no need in the component. On the moment of development of this component there were multiple ways to do that, for instance: 1. jms component which is rather heavyweight to do inter-bundle communication in the same jvm. 2. vm component which is asynchronous and does not support transactions 3. nmr component which can be used in synchronous mode, but does not support pub-sub, although it does not prevent user from registering multiple consuming endpoints with the same name, so the messages are sent only to the first registered nmr-consumer. The new direct-vm component solves the issue with transactions (like synchronous nmr does) but it does not support pub-sub too. To use a dynamic recipient list it's necessary to have some kind of custom code that will resolve addresses of recipients at runtime. In such a case syncronous nmr can be used as well. The benefit of OSGi services is that this is a standard functionality of OSGi runtime and even OSGi api predisposed to work with an array of them. Furthermore you will get all the benefits of OSGi services, i.e. dynamism, priorities, etc. It would be nice if direct-vm allowed to configure pub-sub with all the options of multicast processor. Regards, Sergey I'm a bit skeptic about this component. It seems at first glance that if conflates a few things like osgi service access, multicast, etc... If the goal is to do inter-bundle communication, the new component coming from CAMEL-5370 should already do that and I don't really see the need for the component. For the multicast, using a dynamic recipient list coupled with direct-vm should work. On Tue, May 22, 2012 at 7:57 PM, szh.s...@gmail.com wrote: Hi gurus, Recently I've published camel component that uses OSGi services to communicate between endpoints in different bundles. Here is the link: https://github.com/szhem/camel-osgi I've already raised JIRA issue - https://issues.apache.org/jira/browse/CAMEL-5292 So I'd like to have some feedback if it seems to be useful. Regards, Sergey -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ FuseSource, Integration everywhere http://fusesource.com
Re: Camel OSGi services component
Sergey, I agree on Guillaume remark. We should improve what we have in camel project instead of creating a new component. There is a new one direct-vm which has been created in camel 2.10 (camel-core) to support communication over camelContext when the camel routes runs in the same JVM. Personally I would prefer that we register (like in NMR) the endpoints in the OSGI Registry (= Global registry) and improve camel to also perform a lookup (with or without filter) in this registry to facilitate communication between bundle in a thread safe and transactional compatible way. Regards, Charles On Thu, Jun 21, 2012 at 7:41 AM, Sergey Zhemzhitsky szh.s...@gmail.comwrote: Hi Guillaume, Of course if there is more convenient way to communicate between bundles there is no need in the component. On the moment of development of this component there were multiple ways to do that, for instance: 1. jms component which is rather heavyweight to do inter-bundle communication in the same jvm. 2. vm component which is asynchronous and does not support transactions 3. nmr component which can be used in synchronous mode, but does not support pub-sub, although it does not prevent user from registering multiple consuming endpoints with the same name, so the messages are sent only to the first registered nmr-consumer. The new direct-vm component solves the issue with transactions (like synchronous nmr does) but it does not support pub-sub too. To use a dynamic recipient list it's necessary to have some kind of custom code that will resolve addresses of recipients at runtime. In such a case syncronous nmr can be used as well. The benefit of OSGi services is that this is a standard functionality of OSGi runtime and even OSGi api predisposed to work with an array of them. Furthermore you will get all the benefits of OSGi services, i.e. dynamism, priorities, etc. It would be nice if direct-vm allowed to configure pub-sub with all the options of multicast processor. Regards, Sergey I'm a bit skeptic about this component. It seems at first glance that if conflates a few things like osgi service access, multicast, etc... If the goal is to do inter-bundle communication, the new component coming from CAMEL-5370 should already do that and I don't really see the need for the component. For the multicast, using a dynamic recipient list coupled with direct-vm should work. On Tue, May 22, 2012 at 7:57 PM, szh.s...@gmail.com wrote: Hi gurus, Recently I've published camel component that uses OSGi services to communicate between endpoints in different bundles. Here is the link: https://github.com/szhem/camel-osgi I've already raised JIRA issue - https://issues.apache.org/jira/browse/CAMEL-5292 So I'd like to have some feedback if it seems to be useful. Regards, Sergey
Re: Camel OSGi services component
+1 I like that aproach. It would make the OSGi services component a lot simpler. from(foo:bar).recipientList(osgiServices(myldapfilter)) I guess we can use a similar aproach to achieve load balancing. Not sure if the example below already would work but I am sure we could make it work this way or similar: from(foo:bar).loadbalance().roundRobin().recepientList(osgiServices(myldapfilter)) Christian Am 21.06.2012 08:27, schrieb Guillaume Nodet: Yeah, and I agree leveraging OSGi services for that is a good idea. That's not really what I'm concerned about. The goal is to have a way to multicast a message to a set of endpoint which will be discovered at runtime, and that's not really OSGi specific (though the fact that OSGi has a service registry make that use case very relevant). I'd like to reuse what camel-core provides for that instead of going around and implementing a brand new component. The dynamic recipient list works with an Expression which returns a list of endpoints (either Endpoint or string uris), so why not writing such an expression ? This expression could easily use a ServiceTracker internally to track changes on services and the expression itself could be an osgi filter... from(foo:bar).recipientList(osgiServices(myldapfilter)) We could even maybe make use of the CamelContext internal registry which can do some type of discovery (though the osgi implementation is lacking a lot of stuff). A simple one would at least be some kind of regular expression that would match some endpoints. We may need something slightly more specific for vm:// and direct-vm:// which can be used for cross-camelContext exchanges. And sorry if I seem a bit reluctant, I'm just trying to make things fit more cleanly in camel, and improve camel core where it needs rather than implementing a new component. It just seems that your requirements are not really osgi specific and could be made slightly mode generic. On Thu, Jun 21, 2012 at 7:41 AM, Sergey Zhemzhitskyszh.s...@gmail.com wrote: Hi Guillaume, Of course if there is more convenient way to communicate between bundles there is no need in the component. On the moment of development of this component there were multiple ways to do that, for instance: 1. jms component which is rather heavyweight to do inter-bundle communication in the same jvm. 2. vm component which is asynchronous and does not support transactions 3. nmr component which can be used in synchronous mode, but does not support pub-sub, although it does not prevent user from registering multiple consuming endpoints with the same name, so the messages are sent only to the first registered nmr-consumer. The new direct-vm component solves the issue with transactions (like synchronous nmr does) but it does not support pub-sub too. To use a dynamic recipient list it's necessary to have some kind of custom code that will resolve addresses of recipients at runtime. In such a case syncronous nmr can be used as well. The benefit of OSGi services is that this is a standard functionality of OSGi runtime and even OSGi api predisposed to work with an array of them. Furthermore you will get all the benefits of OSGi services, i.e. dynamism, priorities, etc. It would be nice if direct-vm allowed to configure pub-sub with all the options of multicast processor. Regards, Sergey I'm a bit skeptic about this component. It seems at first glance that if conflates a few things like osgi service access, multicast, etc... If the goal is to do inter-bundle communication, the new component coming from CAMEL-5370 should already do that and I don't really see the need for the component. For the multicast, using a dynamic recipient list coupled with direct-vm should work. On Tue, May 22, 2012 at 7:57 PM,szh.s...@gmail.com wrote: Hi gurus, Recently I've published camel component that uses OSGi services to communicate between endpoints in different bundles. Here is the link: https://github.com/szhem/camel-osgi I've already raised JIRA issue - https://issues.apache.org/jira/browse/CAMEL-5292 So I'd like to have some feedback if it seems to be useful. Regards, Sergey -- Christian Schneider http://www.liquid-reality.de Open Source Architect Talend Application Integration Division http://www.talend.com
Re: Camel OSGi services component
That's really my main goal. If we fit into what already exists more, we'll be able to better leverage everything. On Thu, Jun 21, 2012 at 8:48 AM, Christian Schneider ch...@die-schneider.net wrote: +1 I like that aproach. It would make the OSGi services component a lot simpler. from(foo:bar).recipientList(osgiServices(myldapfilter)) I guess we can use a similar aproach to achieve load balancing. Not sure if the example below already would work but I am sure we could make it work this way or similar: from(foo:bar).loadbalance().roundRobin().recepientList(osgiServices(myldapfilter)) Christian Am 21.06.2012 08:27, schrieb Guillaume Nodet: Yeah, and I agree leveraging OSGi services for that is a good idea. That's not really what I'm concerned about. The goal is to have a way to multicast a message to a set of endpoint which will be discovered at runtime, and that's not really OSGi specific (though the fact that OSGi has a service registry make that use case very relevant). I'd like to reuse what camel-core provides for that instead of going around and implementing a brand new component. The dynamic recipient list works with an Expression which returns a list of endpoints (either Endpoint or string uris), so why not writing such an expression ? This expression could easily use a ServiceTracker internally to track changes on services and the expression itself could be an osgi filter... from(foo:bar).recipientList(osgiServices(myldapfilter)) We could even maybe make use of the CamelContext internal registry which can do some type of discovery (though the osgi implementation is lacking a lot of stuff). A simple one would at least be some kind of regular expression that would match some endpoints. We may need something slightly more specific for vm:// and direct-vm:// which can be used for cross-camelContext exchanges. And sorry if I seem a bit reluctant, I'm just trying to make things fit more cleanly in camel, and improve camel core where it needs rather than implementing a new component. It just seems that your requirements are not really osgi specific and could be made slightly mode generic. On Thu, Jun 21, 2012 at 7:41 AM, Sergey Zhemzhitskyszh.s...@gmail.com wrote: Hi Guillaume, Of course if there is more convenient way to communicate between bundles there is no need in the component. On the moment of development of this component there were multiple ways to do that, for instance: 1. jms component which is rather heavyweight to do inter-bundle communication in the same jvm. 2. vm component which is asynchronous and does not support transactions 3. nmr component which can be used in synchronous mode, but does not support pub-sub, although it does not prevent user from registering multiple consuming endpoints with the same name, so the messages are sent only to the first registered nmr-consumer. The new direct-vm component solves the issue with transactions (like synchronous nmr does) but it does not support pub-sub too. To use a dynamic recipient list it's necessary to have some kind of custom code that will resolve addresses of recipients at runtime. In such a case syncronous nmr can be used as well. The benefit of OSGi services is that this is a standard functionality of OSGi runtime and even OSGi api predisposed to work with an array of them. Furthermore you will get all the benefits of OSGi services, i.e. dynamism, priorities, etc. It would be nice if direct-vm allowed to configure pub-sub with all the options of multicast processor. Regards, Sergey I'm a bit skeptic about this component. It seems at first glance that if conflates a few things like osgi service access, multicast, etc... If the goal is to do inter-bundle communication, the new component coming from CAMEL-5370 should already do that and I don't really see the need for the component. For the multicast, using a dynamic recipient list coupled with direct-vm should work. On Tue, May 22, 2012 at 7:57 PM,szh.s...@gmail.com wrote: Hi gurus, Recently I've published camel component that uses OSGi services to communicate between endpoints in different bundles. Here is the link: https://github.com/szhem/camel-osgi I've already raised JIRA issue - https://issues.apache.org/jira/browse/CAMEL-5292 So I'd like to have some feedback if it seems to be useful. Regards, Sergey -- Christian Schneider http://www.liquid-reality.de Open Source Architect Talend Application Integration Division http://www.talend.com -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ FuseSource, Integration everywhere http://fusesource.com
Re: Camel OSGi services component
Agree, I think that enhancing the existing could achieve this. Regards JB On 06/21/2012 08:51 AM, Guillaume Nodet wrote: That's really my main goal. If we fit into what already exists more, we'll be able to better leverage everything. On Thu, Jun 21, 2012 at 8:48 AM, Christian Schneider ch...@die-schneider.net wrote: +1 I like that aproach. It would make the OSGi services component a lot simpler. from(foo:bar).recipientList(osgiServices(myldapfilter)) I guess we can use a similar aproach to achieve load balancing. Not sure if the example below already would work but I am sure we could make it work this way or similar: from(foo:bar).loadbalance().roundRobin().recepientList(osgiServices(myldapfilter)) Christian Am 21.06.2012 08:27, schrieb Guillaume Nodet: Yeah, and I agree leveraging OSGi services for that is a good idea. That's not really what I'm concerned about. The goal is to have a way to multicast a message to a set of endpoint which will be discovered at runtime, and that's not really OSGi specific (though the fact that OSGi has a service registry make that use case very relevant). I'd like to reuse what camel-core provides for that instead of going around and implementing a brand new component. The dynamic recipient list works with an Expression which returns a list of endpoints (either Endpoint or string uris), so why not writing such an expression ? This expression could easily use a ServiceTracker internally to track changes on services and the expression itself could be an osgi filter... from(foo:bar).recipientList(osgiServices(myldapfilter)) We could even maybe make use of the CamelContext internal registry which can do some type of discovery (though the osgi implementation is lacking a lot of stuff). A simple one would at least be some kind of regular expression that would match some endpoints. We may need something slightly more specific for vm:// and direct-vm:// which can be used for cross-camelContext exchanges. And sorry if I seem a bit reluctant, I'm just trying to make things fit more cleanly in camel, and improve camel core where it needs rather than implementing a new component. It just seems that your requirements are not really osgi specific and could be made slightly mode generic. On Thu, Jun 21, 2012 at 7:41 AM, Sergey Zhemzhitskyszh.s...@gmail.com wrote: Hi Guillaume, Of course if there is more convenient way to communicate between bundles there is no need in the component. On the moment of development of this component there were multiple ways to do that, for instance: 1. jms component which is rather heavyweight to do inter-bundle communication in the same jvm. 2. vm component which is asynchronous and does not support transactions 3. nmr component which can be used in synchronous mode, but does not support pub-sub, although it does not prevent user from registering multiple consuming endpoints with the same name, so the messages are sent only to the first registered nmr-consumer. The new direct-vm component solves the issue with transactions (like synchronous nmr does) but it does not support pub-sub too. To use a dynamic recipient list it's necessary to have some kind of custom code that will resolve addresses of recipients at runtime. In such a case syncronous nmr can be used as well. The benefit of OSGi services is that this is a standard functionality of OSGi runtime and even OSGi api predisposed to work with an array of them. Furthermore you will get all the benefits of OSGi services, i.e. dynamism, priorities, etc. It would be nice if direct-vm allowed to configure pub-sub with all the options of multicast processor. Regards, Sergey I'm a bit skeptic about this component. It seems at first glance that if conflates a few things like osgi service access, multicast, etc... If the goal is to do inter-bundle communication, the new component coming from CAMEL-5370 should already do that and I don't really see the need for the component. For the multicast, using a dynamic recipient list coupled with direct-vm should work. On Tue, May 22, 2012 at 7:57 PM,szh.s...@gmail.comwrote: Hi gurus, Recently I've published camel component that uses OSGi services to communicate between endpoints in different bundles. Here is the link: https://github.com/szhem/camel-osgi I've already raised JIRA issue - https://issues.apache.org/jira/browse/CAMEL-5292 So I'd like to have some feedback if it seems to be useful. Regards, Sergey -- Christian Schneider http://www.liquid-reality.de Open Source Architect Talend Application Integration Division http://www.talend.com -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Re: Camel OSGi services component
Hello, guys, I agree that if the camel-core could be enhanced to achieve easy cross-context communication in the single JVM it would be fine. In that case I would not tire the core to OSGi anyhow to be really environment-independent. I suppose that camel context could be published into the JNDI to be retrieved at some time lately to discover consuming endpoints. Thus we can achieve the similar behavior in different environments and from(foo:bar).recipientList(osgiServices(myldapfilter)) would become from(foo:bar).recipientList(vm(myfilter)) Regards, Sergey Agree, I think that enhancing the existing could achieve this. Regards JB On 06/21/2012 08:51 AM, Guillaume Nodet wrote: That's really my main goal. If we fit into what already exists more, we'll be able to better leverage everything. On Thu, Jun 21, 2012 at 8:48 AM, Christian Schneider ch...@die-schneider.net wrote: +1 I like that aproach. It would make the OSGi services component a lot simpler. from(foo:bar).recipientList(osgiServices(myldapfilter)) I guess we can use a similar aproach to achieve load balancing. Not sure if the example below already would work but I am sure we could make it work this way or similar: from(foo:bar).loadbalance().roundRobin().recepientList(osgiServices(myldapfilter)) Christian Am 21.06.2012 08:27, schrieb Guillaume Nodet: Yeah, and I agree leveraging OSGi services for that is a good idea. That's not really what I'm concerned about. The goal is to have a way to multicast a message to a set of endpoint which will be discovered at runtime, and that's not really OSGi specific (though the fact that OSGi has a service registry make that use case very relevant). I'd like to reuse what camel-core provides for that instead of going around and implementing a brand new component. The dynamic recipient list works with an Expression which returns a list of endpoints (either Endpoint or string uris), so why not writing such an expression ? This expression could easily use a ServiceTracker internally to track changes on services and the expression itself could be an osgi filter... from(foo:bar).recipientList(osgiServices(myldapfilter)) We could even maybe make use of the CamelContext internal registry which can do some type of discovery (though the osgi implementation is lacking a lot of stuff). A simple one would at least be some kind of regular expression that would match some endpoints. We may need something slightly more specific for vm:// and direct-vm:// which can be used for cross-camelContext exchanges. And sorry if I seem a bit reluctant, I'm just trying to make things fit more cleanly in camel, and improve camel core where it needs rather than implementing a new component. It just seems that your requirements are not really osgi specific and could be made slightly mode generic. On Thu, Jun 21, 2012 at 7:41 AM, Sergey Zhemzhitskyszh.s...@gmail.com wrote: Hi Guillaume, Of course if there is more convenient way to communicate between bundles there is no need in the component. On the moment of development of this component there were multiple ways to do that, for instance: 1. jms component which is rather heavyweight to do inter-bundle communication in the same jvm. 2. vm component which is asynchronous and does not support transactions 3. nmr component which can be used in synchronous mode, but does not support pub-sub, although it does not prevent user from registering multiple consuming endpoints with the same name, so the messages are sent only to the first registered nmr-consumer. The new direct-vm component solves the issue with transactions (like synchronous nmr does) but it does not support pub-sub too. To use a dynamic recipient list it's necessary to have some kind of custom code that will resolve addresses of recipients at runtime. In such a case syncronous nmr can be used as well. The benefit of OSGi services is that this is a standard functionality of OSGi runtime and even OSGi api predisposed to work with an array of them. Furthermore you will get all the benefits of OSGi services, i.e. dynamism, priorities, etc. It would be nice if direct-vm allowed to configure pub-sub with all the options of multicast processor. Regards, Sergey I'm a bit skeptic about this component. It seems at first glance that if conflates a few things like osgi service access, multicast, etc... If the goal is to do inter-bundle communication, the new component coming from CAMEL-5370 should already do that and I don't really see the need for the component. For the multicast, using a dynamic recipient list coupled with direct-vm should work. On Tue, May 22, 2012 at 7:57 PM,szh.s...@gmail.comwrote: Hi gurus, Recently I've published camel component that uses OSGi services to communicate between endpoints in different bundles. Here is the link: https://github.com/szhem/camel-osgi I've already
Re: Camel OSGi services component
Hi Sergey, the component looks pretty good already. There is one thing though I would like to discuss. More or less the core of this component is the OSGi service we use to communicate between the bundles. You currently use the camel Processor interface for this. While this is quite suitable for pure camel to camel communication I wonder if we could come up with an interface that is not tied to camel. The Processor interfaces indirectly references a lot of the camel core code. I wonder if we could design a simple self contained interface that would also be reuseable for other projects to do a generic communication with camel. Christian Am 22.05.2012 19:57, schrieb szh.s...@gmail.com: Hi gurus, Recently I've published camel component that uses OSGi services to communicate between endpoints in different bundles. Here is the link: https://github.com/szhem/camel-osgi I've already raised JIRA issue - https://issues.apache.org/jira/browse/CAMEL-5292 So I'd like to have some feedback if it seems to be useful. Regards, Sergey -- Christian Schneider http://www.liquid-reality.de Open Source Architect Talend Application Integration Division http://www.talend.com
Re: Camel OSGi services component
Excellent remark Christian. I have also another concern regrading to the component which is : Does it support TX propagation with or without Spring ? https://issues.apache.org/jira/browse/CAMEL-5368 https://issues.apache.org/jira/browse/CAMEL-5292 On Wed, Jun 20, 2012 at 10:36 AM, Christian Schneider ch...@die-schneider.net wrote: Hi Sergey, the component looks pretty good already. There is one thing though I would like to discuss. More or less the core of this component is the OSGi service we use to communicate between the bundles. You currently use the camel Processor interface for this. While this is quite suitable for pure camel to camel communication I wonder if we could come up with an interface that is not tied to camel. The Processor interfaces indirectly references a lot of the camel core code. I wonder if we could design a simple self contained interface that would also be reuseable for other projects to do a generic communication with camel. Christian Am 22.05.2012 19:57, schrieb szh.s...@gmail.com: Hi gurus, Recently I've published camel component that uses OSGi services to communicate between endpoints in different bundles. Here is the link: https://github.com/szhem/**camel-osgihttps://github.com/szhem/camel-osgi I've already raised JIRA issue - https://issues.apache.org/** jira/browse/CAMEL-5292 https://issues.apache.org/jira/browse/CAMEL-5292 So I'd like to have some feedback if it seems to be useful. Regards, Sergey -- Christian Schneider http://www.liquid-reality.de Open Source Architect Talend Application Integration Division http://www.talend.com
Re: Camel OSGi services component
I'm a bit skeptic about this component. It seems at first glance that if conflates a few things like osgi service access, multicast, etc... If the goal is to do inter-bundle communication, the new component coming from CAMEL-5370 should already do that and I don't really see the need for the component. For the multicast, using a dynamic recipient list coupled with direct-vm should work. On Tue, May 22, 2012 at 7:57 PM, szh.s...@gmail.com wrote: Hi gurus, Recently I've published camel component that uses OSGi services to communicate between endpoints in different bundles. Here is the link: https://github.com/szhem/camel-osgi I've already raised JIRA issue - https://issues.apache.org/jira/browse/CAMEL-5292 So I'd like to have some feedback if it seems to be useful. Regards, Sergey -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ FuseSource, Integration everywhere http://fusesource.com
Re: Camel OSGi services component
Hello Charles, The component does not contain any transaction-specific or spring-specific logic. Handling of transactions should be done using transactional-client (http://camel.apache.org/transactional-client.html) EIP. Basically, if you need to call the consuming bundles in a transaction started by a producing bundle, everything should work out of the box, as OSGi guaranties that the services are invoked synchronously in the same thread. If you have to support different propagations for different bundles, like this from(direct:start).id(producer).transacted(PROPAGATION_REQUIRED).to(osgi:multicast:consumer); from(osgi:consumer).id(consumer1).transacted(PROPAGATION_REQUIRES_NEW).to(mock:consumer1); from(osgi:consumer).id(consumer2).transacted(PROPAGATION_SUPPORTS).to(mock:consumer2); you have to export the transaction manager as OSGi service from the producing bundle, and import it in all the consuming bundles to configure org.apache.camel.spring.spi.SpringTransactionPolicy'es properly. Currently I'm considering to implement an integration test to show how to do that. Regards, Sergey Excellent remark Christian. I have also another concern regrading to the component which is : Does it support TX propagation with or without Spring ? https://issues.apache.org/jira/browse/CAMEL-5368 https://issues.apache.org/jira/browse/CAMEL-5292 On Wed, Jun 20, 2012 at 10:36 AM, Christian Schneider ch...@die-schneider.net wrote: Hi Sergey, the component looks pretty good already. There is one thing though I would like to discuss. More or less the core of this component is the OSGi service we use to communicate between the bundles. You currently use the camel Processor interface for this. While this is quite suitable for pure camel to camel communication I wonder if we could come up with an interface that is not tied to camel. The Processor interfaces indirectly references a lot of the camel core code. I wonder if we could design a simple self contained interface that would also be reuseable for other projects to do a generic communication with camel. Christian Am 22.05.2012 19:57, schrieb szh.s...@gmail.com: Hi gurus, Recently I've published camel component that uses OSGi services to communicate between endpoints in different bundles. Here is the link: https://github.com/szhem/**camel-osgihttps://github.com/szhem/camel-osgi I've already raised JIRA issue - https://issues.apache.org/** jira/browse/CAMEL-5292 https://issues.apache.org/jira/browse/CAMEL-5292 So I'd like to have some feedback if it seems to be useful. Regards, Sergey -- Christian Schneider http://www.liquid-reality.de Open Source Architect Talend Application Integration Division http://www.talend.com
Re: Camel OSGi services component
Hello Christian, Firstly I thought about some kind of indirect dependency on camel, but I suppose that such an indirection will complicate the component with copying of headers, bodies, properties, etc. from and to a camel exchange in case of duplication of camel exchange api (lightweight analogues of camel exchanges). The self contained interface will be provided as some kind of additional module of the component, so there will be a dependency on the component and in my opinion there is no a big difference between depending on the camel api or the camel component api. What do you think about something like a bean binding (http://camel.apache.org/bean-binding.html) from the consumer side? In that case almost any interface can be used as published OSGi service to process exchanges. Regards, Sergey Hi Sergey, the component looks pretty good already. There is one thing though I would like to discuss. More or less the core of this component is the OSGi service we use to communicate between the bundles. You currently use the camel Processor interface for this. While this is quite suitable for pure camel to camel communication I wonder if we could come up with an interface that is not tied to camel. The Processor interfaces indirectly references a lot of the camel core code. I wonder if we could design a simple self contained interface that would also be reuseable for other projects to do a generic communication with camel. Christian Am 22.05.2012 19:57, schrieb szh.s...@gmail.com: Hi gurus, Recently I've published camel component that uses OSGi services to communicate between endpoints in different bundles. Here is the link: https://github.com/szhem/camel-osgi I've already raised JIRA issue - https://issues.apache.org/jira/browse/CAMEL-5292 So I'd like to have some feedback if it seems to be useful. Regards, Sergey
Re: Camel OSGi services component
Hi Guillaume, Of course if there is more convenient way to communicate between bundles there is no need in the component. On the moment of development of this component there were multiple ways to do that, for instance: 1. jms component which is rather heavyweight to do inter-bundle communication in the same jvm. 2. vm component which is asynchronous and does not support transactions 3. nmr component which can be used in synchronous mode, but does not support pub-sub, although it does not prevent user from registering multiple consuming endpoints with the same name, so the messages are sent only to the first registered nmr-consumer. The new direct-vm component solves the issue with transactions (like synchronous nmr does) but it does not support pub-sub too. To use a dynamic recipient list it's necessary to have some kind of custom code that will resolve addresses of recipients at runtime. In such a case syncronous nmr can be used as well. The benefit of OSGi services is that this is a standard functionality of OSGi runtime and even OSGi api predisposed to work with an array of them. Furthermore you will get all the benefits of OSGi services, i.e. dynamism, priorities, etc. It would be nice if direct-vm allowed to configure pub-sub with all the options of multicast processor. Regards, Sergey I'm a bit skeptic about this component. It seems at first glance that if conflates a few things like osgi service access, multicast, etc... If the goal is to do inter-bundle communication, the new component coming from CAMEL-5370 should already do that and I don't really see the need for the component. For the multicast, using a dynamic recipient list coupled with direct-vm should work. On Tue, May 22, 2012 at 7:57 PM, szh.s...@gmail.com wrote: Hi gurus, Recently I've published camel component that uses OSGi services to communicate between endpoints in different bundles. Here is the link: https://github.com/szhem/camel-osgi I've already raised JIRA issue - https://issues.apache.org/jira/browse/CAMEL-5292 So I'd like to have some feedback if it seems to be useful. Regards, Sergey
Re: Camel OSGi services component
Hi We are in the process of getting Camel 2.10 done and released. Your component looks interesting but I would like more time to look into it, and also for the SMX / Karaf team to take a look at was, as its OSGi based. And I wonder if the scheme name of osgi is a good name, as osgi is a broad term? We can surely introduce this component in a patch release of 2.10 if there is no changes to the camel-core. And also at 2.11. But if all is well, then I dont see an issue to introduce it in 2.10.1. We have done this in the past adding new components to a patch release. On Sat, Jun 2, 2012 at 6:37 PM, Sergey Zhemzhitsky szh.s...@gmail.com wrote: Hi Claus, Recently docs and integration tests of the component have been updated. I suppose it's ready for now and all missing pieces and features can be added later. Regards, Sergey On Wed, May 30, 2012 at 8:41 PM, Sergey Zhemzhitsky szh.s...@gmail.com wrote: Hi Claus, The component can be used right now without any additions, but I'd like to include some integration tests which will check that: 1. Any camel processor (even not included into the camel route) can be published into the OSGi service registry to process exchanges. 2. Multiple producers can send exchanges to one/many consumers. Everything should work out of the box, but the samples can be rather useful. Also I'd like to update docs with the samples based on the points above. One more interesting thing is investigating into whether the component can be integrated with DOSGi easily, but I suppose it can be postponed a little bit as it's not very important, but rather useful feature. Yeah I suggest to get those pieces implemented first. DOSGi can come later. For example CXF supports DOSGi, as well Fuse Fabric. Regards, Sergey On Tue, May 22, 2012 at 7:57 PM, szh.s...@gmail.com wrote: Hi gurus, Recently I've published camel component that uses OSGi services to communicate between endpoints in different bundles. Here is the link: https://github.com/szhem/camel-osgi I've already raised JIRA issue - https://issues.apache.org/jira/browse/CAMEL-5292 So I'd like to have some feedback if it seems to be useful. Regards, Sergey Sergey at first glance this seem really useful. Good work. Is there any missing functionality / features / tests etc? -- Claus Ibsen - FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen
Re: Camel OSGi services component
Hi guys, I will take a look. Agree with you that osgi name is not the best name. Thanks Regards JB On 06/07/2012 09:32 AM, Claus Ibsen wrote: Hi We are in the process of getting Camel 2.10 done and released. Your component looks interesting but I would like more time to look into it, and also for the SMX / Karaf team to take a look at was, as its OSGi based. And I wonder if the scheme name of osgi is a good name, as osgi is a broad term? We can surely introduce this component in a patch release of 2.10 if there is no changes to the camel-core. And also at 2.11. But if all is well, then I dont see an issue to introduce it in 2.10.1. We have done this in the past adding new components to a patch release. On Sat, Jun 2, 2012 at 6:37 PM, Sergey Zhemzhitskyszh.s...@gmail.com wrote: Hi Claus, Recently docs and integration tests of the component have been updated. I suppose it's ready for now and all missing pieces and features can be added later. Regards, Sergey On Wed, May 30, 2012 at 8:41 PM, Sergey Zhemzhitskyszh.s...@gmail.com wrote: Hi Claus, The component can be used right now without any additions, but I'd like to include some integration tests which will check that: 1. Any camel processor (even not included into the camel route) can be published into the OSGi service registry to process exchanges. 2. Multiple producers can send exchanges to one/many consumers. Everything should work out of the box, but the samples can be rather useful. Also I'd like to update docs with the samples based on the points above. One more interesting thing is investigating into whether the component can be integrated with DOSGi easily, but I suppose it can be postponed a little bit as it's not very important, but rather useful feature. Yeah I suggest to get those pieces implemented first. DOSGi can come later. For example CXF supports DOSGi, as well Fuse Fabric. Regards, Sergey On Tue, May 22, 2012 at 7:57 PM,szh.s...@gmail.com wrote: Hi gurus, Recently I've published camel component that uses OSGi services to communicate between endpoints in different bundles. Here is the link: https://github.com/szhem/camel-osgi I've already raised JIRA issue - https://issues.apache.org/jira/browse/CAMEL-5292 So I'd like to have some feedback if it seems to be useful. Regards, Sergey Sergey at first glance this seem really useful. Good work. Is there any missing functionality / features / tests etc? -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Re: Camel OSGi services component
Hello everybody, Thanks for considering the component. osgi name is not the best name I suppose the name should be short, should prevent misunderstandings about the environment where it can be used, possibly it should describe what the component is supposed to do. Although osgi is widely-used term, it seems to be ok in the context of a camel components in my opinion. Among the possible alternatives like dynamic-service, service, osgi, osgi-service, whiteboard, osgi-whiteboard, etc., I would give the first place to osgi (for brevity) and the second - to osgi-service (for descriptiveness). If you have any other ideas of how the component should be named, please share them. Regards, Sergey Hi guys, I will take a look. Agree with you that osgi name is not the best name. Thanks Regards JB On 06/07/2012 09:32 AM, Claus Ibsen wrote: Hi We are in the process of getting Camel 2.10 done and released. Your component looks interesting but I would like more time to look into it, and also for the SMX / Karaf team to take a look at was, as its OSGi based. And I wonder if the scheme name of osgi is a good name, as osgi is a broad term? We can surely introduce this component in a patch release of 2.10 if there is no changes to the camel-core. And also at 2.11. But if all is well, then I dont see an issue to introduce it in 2.10.1. We have done this in the past adding new components to a patch release. On Sat, Jun 2, 2012 at 6:37 PM, Sergey Zhemzhitskyszh.s...@gmail.com wrote: Hi Claus, Recently docs and integration tests of the component have been updated. I suppose it's ready for now and all missing pieces and features can be added later. Regards, Sergey On Wed, May 30, 2012 at 8:41 PM, Sergey Zhemzhitskyszh.s...@gmail.com wrote: Hi Claus, The component can be used right now without any additions, but I'd like to include some integration tests which will check that: 1. Any camel processor (even not included into the camel route) can be published into the OSGi service registry to process exchanges. 2. Multiple producers can send exchanges to one/many consumers. Everything should work out of the box, but the samples can be rather useful. Also I'd like to update docs with the samples based on the points above. One more interesting thing is investigating into whether the component can be integrated with DOSGi easily, but I suppose it can be postponed a little bit as it's not very important, but rather useful feature. Yeah I suggest to get those pieces implemented first. DOSGi can come later. For example CXF supports DOSGi, as well Fuse Fabric. Regards, Sergey On Tue, May 22, 2012 at 7:57 PM,szh.s...@gmail.com wrote: Hi gurus, Recently I've published camel component that uses OSGi services to communicate between endpoints in different bundles. Here is the link: https://github.com/szhem/camel-osgi I've already raised JIRA issue - https://issues.apache.org/jira/browse/CAMEL-5292 So I'd like to have some feedback if it seems to be useful. Regards, Sergey Sergey at first glance this seem really useful. Good work. Is there any missing functionality / features / tests etc?
Re: Camel OSGi services component
On Wed, May 30, 2012 at 8:41 PM, Sergey Zhemzhitsky szh.s...@gmail.com wrote: Hi Claus, The component can be used right now without any additions, but I'd like to include some integration tests which will check that: 1. Any camel processor (even not included into the camel route) can be published into the OSGi service registry to process exchanges. 2. Multiple producers can send exchanges to one/many consumers. Everything should work out of the box, but the samples can be rather useful. Also I'd like to update docs with the samples based on the points above. One more interesting thing is investigating into whether the component can be integrated with DOSGi easily, but I suppose it can be postponed a little bit as it's not very important, but rather useful feature. Yeah I suggest to get those pieces implemented first. DOSGi can come later. For example CXF supports DOSGi, as well Fuse Fabric. Regards, Sergey On Tue, May 22, 2012 at 7:57 PM, szh.s...@gmail.com wrote: Hi gurus, Recently I've published camel component that uses OSGi services to communicate between endpoints in different bundles. Here is the link: https://github.com/szhem/camel-osgi I've already raised JIRA issue - https://issues.apache.org/jira/browse/CAMEL-5292 So I'd like to have some feedback if it seems to be useful. Regards, Sergey Sergey at first glance this seem really useful. Good work. Is there any missing functionality / features / tests etc? -- Claus Ibsen - FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen
Re: Camel OSGi services component
Hi Claus, Recently docs and integration tests of the component have been updated. I suppose it's ready for now and all missing pieces and features can be added later. Regards, Sergey On Wed, May 30, 2012 at 8:41 PM, Sergey Zhemzhitsky szh.s...@gmail.com wrote: Hi Claus, The component can be used right now without any additions, but I'd like to include some integration tests which will check that: 1. Any camel processor (even not included into the camel route) can be published into the OSGi service registry to process exchanges. 2. Multiple producers can send exchanges to one/many consumers. Everything should work out of the box, but the samples can be rather useful. Also I'd like to update docs with the samples based on the points above. One more interesting thing is investigating into whether the component can be integrated with DOSGi easily, but I suppose it can be postponed a little bit as it's not very important, but rather useful feature. Yeah I suggest to get those pieces implemented first. DOSGi can come later. For example CXF supports DOSGi, as well Fuse Fabric. Regards, Sergey On Tue, May 22, 2012 at 7:57 PM, szh.s...@gmail.com wrote: Hi gurus, Recently I've published camel component that uses OSGi services to communicate between endpoints in different bundles. Here is the link: https://github.com/szhem/camel-osgi I've already raised JIRA issue - https://issues.apache.org/jira/browse/CAMEL-5292 So I'd like to have some feedback if it seems to be useful. Regards, Sergey Sergey at first glance this seem really useful. Good work. Is there any missing functionality / features / tests etc?
Re: Camel OSGi services component
On Tue, May 22, 2012 at 7:57 PM, szh.s...@gmail.com wrote: Hi gurus, Recently I've published camel component that uses OSGi services to communicate between endpoints in different bundles. Here is the link: https://github.com/szhem/camel-osgi I've already raised JIRA issue - https://issues.apache.org/jira/browse/CAMEL-5292 So I'd like to have some feedback if it seems to be useful. Regards, Sergey Sergey at first glance this seem really useful. Good work. Is there any missing functionality / features / tests etc? -- Claus Ibsen - FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen
Re: Camel OSGi services component
Hi Claus, The component can be used right now without any additions, but I'd like to include some integration tests which will check that: 1. Any camel processor (even not included into the camel route) can be published into the OSGi service registry to process exchanges. 2. Multiple producers can send exchanges to one/many consumers. Everything should work out of the box, but the samples can be rather useful. Also I'd like to update docs with the samples based on the points above. One more interesting thing is investigating into whether the component can be integrated with DOSGi easily, but I suppose it can be postponed a little bit as it's not very important, but rather useful feature. Regards, Sergey On Tue, May 22, 2012 at 7:57 PM, szh.s...@gmail.com wrote: Hi gurus, Recently I've published camel component that uses OSGi services to communicate between endpoints in different bundles. Here is the link: https://github.com/szhem/camel-osgi I've already raised JIRA issue - https://issues.apache.org/jira/browse/CAMEL-5292 So I'd like to have some feedback if it seems to be useful. Regards, Sergey Sergey at first glance this seem really useful. Good work. Is there any missing functionality / features / tests etc?
Re: Camel OSGi services component
Hi very cool component to implement the observer pattern in camel blueprint just a small question: how can i have a async calling of the listeners? (mutlicast is sync per definition)? On 23.05.2012 18:29, szh.s...@gmail.com wrote: Hi James, references are perfect if you have a single processor, if you have more than one processor that may come and go you will have to write custom code to publish to all of these processors. The main goal I was trying to achieve is to send an exchange to multiple osgi endpoints and to load balance between multiple osgi endpoints which can be published at any time, so their URIs are not known at the deployment time. The simple example is publishing messages to multiple systems. Here is the route in the producing bundle: from(direct:start).to(osgi:multicast:consumer) In the consuming bundle 1 you declare the route to process the exchange like this from(osgi:consumer).process(processorA); If after the time you would like to subscribe the bundle B to the same exchanges, the only thing you have to do is to deploy another bundle with route like this: from(osgi:consumer).process(processorB); Of course you can use jms topics or something like this but I suppose osgi component is more lightweight and does not involve additional software. Moreover jms does not support aggregation strategies so you will have to complicate your route with aggregate eip. For multicasting to multiple bundles you can also involve vm endpoints, but they don't support synchronous multicasting, aggregation strategies, stopping on failures, etc. What exactly are you trying to achieve? You just want to try to talk to OSGi services? Can't you just do that withreferences and beanRef? On Tue, May 22, 2012 at 1:57 PM,szh.s...@gmail.com wrote: Hi gurus, Recently I've published camel component that uses OSGi services to communicate between endpoints in different bundles. Here is the link: https://github.com/szhem/camel-osgi I've already raised JIRA issue - https://issues.apache.org/jira/browse/CAMEL-5292 So I'd like to have some feedback if it seems to be useful. Regards, Sergey -- Michael Sueess Senior Software Engineer basis06 AG, Birkenweg 61, CH-3013 Bern - Fon +41 31 311 32 22 http://www.basis06.ch - source of smart business Keine News verpassen? http://www.basis06.ch/newsletter-registration.html Schon gebloggt? http://blog.basis06.ch
Re: Camel OSGi services component
Hello Michael, To call the listeners asynchronously you can use the following uri: osgi:multicast:myEndpoint?parallelProcessing=true. Here is some docs aboutpredefinedparametersfor osgi:multicast producers: https://github.com/szhem/camel-osgi#multicasting-to-multiple-osgi-bundles. Note that the caller thread will still wait until all messages has been processed, as this is the behavior of the MulticastProcessor that is used internally. I suppose that support of fire-and-forget behavior (i.e. one-way sending) may be pretty useful. The parameters are almost identical to multicast eip ones (http://camel.apache.org/multicast.html#Multicast-Options) Regards, Sergey Hi very cool component to implement the observer pattern in camel blueprint just a small question: how can i have a async calling of the listeners? (mutlicast is sync per definition)? On 23.05.2012 18:29, szh.s...@gmail.com wrote: Hi James, references are perfect if you have a single processor, if you have more than one processor that may come and go you will have to write custom code to publish to all of these processors. The main goal I was trying to achieve is to send an exchange to multiple osgi endpoints and to load balance between multiple osgi endpoints which can be published at any time, so their URIs are not known at the deployment time. The simple example is publishing messages to multiple systems. Here is the route in the producing bundle: from(direct:start).to(osgi:multicast:consumer) In the consuming bundle 1 you declare the route to process the exchange like this from(osgi:consumer).process(processorA); If after the time you would like to subscribe the bundle B to the same exchanges, the only thing you have to do is to deploy another bundle with route like this: from(osgi:consumer).process(processorB); Of course you can use jms topics or something like this but I suppose osgi component is more lightweight and does not involve additional software. Moreover jms does not support aggregation strategies so you will have to complicate your route with aggregate eip. For multicasting to multiple bundles you can also involve vm endpoints, but they don't support synchronous multicasting, aggregation strategies, stopping on failures, etc. What exactly are you trying to achieve? You just want to try to talk to OSGi services? Can't you just do that withreferences and beanRef? On Tue, May 22, 2012 at 1:57 PM,szh.s...@gmail.com wrote: Hi gurus, Recently I've published camel component that uses OSGi services to communicate between endpoints in different bundles. Here is the link: https://github.com/szhem/camel-osgi I've already raised JIRA issue - https://issues.apache.org/jira/browse/CAMEL-5292 So I'd like to have some feedback if it seems to be useful. Regards, Sergey
Re: Camel OSGi services component
What exactly are you trying to achieve? You just want to try to talk to OSGi services? Can't you just do that with references and beanRef? On Tue, May 22, 2012 at 1:57 PM, szh.s...@gmail.com wrote: Hi gurus, Recently I've published camel component that uses OSGi services to communicate between endpoints in different bundles. Here is the link: https://github.com/szhem/camel-osgi I've already raised JIRA issue - https://issues.apache.org/jira/browse/CAMEL-5292 So I'd like to have some feedback if it seems to be useful. Regards, Sergey
Re: Camel OSGi services component
There are some, myself included, who, for whatever reason, don't use Spring or Karaf. Don On Tue, May 22, 2012 at 3:19 PM, James Carman ja...@carmanconsulting.com wrote: What exactly are you trying to achieve? You just want to try to talk to OSGi services? Can't you just do that with references and beanRef? On Tue, May 22, 2012 at 1:57 PM, szh.s...@gmail.com wrote: Hi gurus, Recently I've published camel component that uses OSGi services to communicate between endpoints in different bundles. Here is the link: https://github.com/szhem/camel-osgi I've already raised JIRA issue - https://issues.apache.org/jira/browse/CAMEL-5292 So I'd like to have some feedback if it seems to be useful. Regards, Sergey
Re: Camel OSGi services component
Do you use Blueprint? On Wed, May 23, 2012 at 11:24 AM, Donald Whytock dwhyt...@gmail.com wrote: There are some, myself included, who, for whatever reason, don't use Spring or Karaf. Don On Tue, May 22, 2012 at 3:19 PM, James Carman ja...@carmanconsulting.com wrote: What exactly are you trying to achieve? You just want to try to talk to OSGi services? Can't you just do that with references and beanRef? On Tue, May 22, 2012 at 1:57 PM, szh.s...@gmail.com wrote: Hi gurus, Recently I've published camel component that uses OSGi services to communicate between endpoints in different bundles. Here is the link: https://github.com/szhem/camel-osgi I've already raised JIRA issue - https://issues.apache.org/jira/browse/CAMEL-5292 So I'd like to have some feedback if it seems to be useful. Regards, Sergey
Re: Camel OSGi services component
Hi James, references are perfect if you have a single processor, if you have more than one processor that may come and go you will have to write custom code to publish to all of these processors. The main goal I was trying to achieve is to send an exchange to multiple osgi endpoints and to load balance between multiple osgi endpoints which can be published at any time, so their URIs are not known at the deployment time. The simple example is publishing messages to multiple systems. Here is the route in the producing bundle: from(direct:start).to(osgi:multicast:consumer) In the consuming bundle 1 you declare the route to process the exchange like this from(osgi:consumer).process(processorA); If after the time you would like to subscribe the bundle B to the same exchanges, the only thing you have to do is to deploy another bundle with route like this: from(osgi:consumer).process(processorB); Of course you can use jms topics or something like this but I suppose osgi component is more lightweight and does not involve additional software. Moreover jms does not support aggregation strategies so you will have to complicate your route with aggregate eip. For multicasting to multiple bundles you can also involve vm endpoints, but they don't support synchronous multicasting, aggregation strategies, stopping on failures, etc. What exactly are you trying to achieve? You just want to try to talk to OSGi services? Can't you just do that with references and beanRef? On Tue, May 22, 2012 at 1:57 PM, szh.s...@gmail.com wrote: Hi gurus, Recently I've published camel component that uses OSGi services to communicate between endpoints in different bundles. Here is the link: https://github.com/szhem/camel-osgi I've already raised JIRA issue - https://issues.apache.org/jira/browse/CAMEL-5292 So I'd like to have some feedback if it seems to be useful. Regards, Sergey -- Best regards, szhmailto:szh.s...@gmail.com
Camel OSGi services component
Hi gurus, Recently I've published camel component that uses OSGi services to communicate between endpoints in different bundles. Here is the link: https://github.com/szhem/camel-osgi I've already raised JIRA issue - https://issues.apache.org/jira/browse/CAMEL-5292 So I'd like to have some feedback if it seems to be useful. Regards, Sergey
