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
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com
