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