camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Zhemzhitsky <>
Subject Re: Camel OSGi services component
Date Sun, 24 Jun 2012 12:14:29 GMT
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
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


> 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 <> wrote:
>> On Fri, Jun 22, 2012 at 10:41 PM, Sergey Zhemzhitsky <> 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 <>
>>>>> 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:
>>>>> 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
>>>>>>> we'll be able to better leverage everything.
>>>>>>> On Thu, Jun 21, 2012 at 8:48 AM, Christian Schneider
>>>>>>> <>  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
>>>>>>>>> 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
>>>>>>>>> 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
>>>>>>>>> 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
>>>>>>>>> would match some endpoints.  We may need something slightly
>>>>>>>>> specific for vm:// and direct-vm:// which can be used
>>>>>>>>> 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<>
>>>>>>>>>   wrote:
>>>>>>>>>> Hi Guillaume,
>>>>>>>>>> Of course if there is more convenient way to communicate
>>>>>>>>>> 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
>>>>>>>>>> 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
>>>>>>>>>> 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,<>
>>>>>>>>>>>> Hi gurus,
>>>>>>>>>>>> Recently  I've  published  camel  component
that uses OSGi services to
>>>>>>>>>>>> communicate between endpoints in different
>>>>>>>>>>>> Here is the link:
>>>>>>>>>>>> I've already raised JIRA issue -
>>>>>>>>>>>> So I'd like to have some feedback if it seems
to be useful.
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Sergey
>>>>>>>> --
>>>>>>>> Christian Schneider
>>>>>>>> Open Source Architect
>>>>>>>> Talend Application Integration Division
>> --
>> Claus Ibsen
>> -----------------
>> FuseSource
>> Email:
>> Web:
>> Twitter: davsclaus, fusenews
>> Blog:
>> Author of Camel in Action:

View raw message