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 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 >>>>>>>>> >>>>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Christian Schneider >>>>> http://www.liquid-reality.de >>>>> >>>>> Open Source Architect >>>>> Talend Application Integration Division http://www.talend.com >>>>> >>>> >>>> >>>> >>
