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 Fri, 22 Jun 2012 04:33:53 GMT
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


would become



> 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
>> <>  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<>
>>>>   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
>>>>> 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
>>>>>> 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,<>    wrote:
>>>>>>> Hi gurus,
>>>>>>> Recently  I've  published  camel  component that uses OSGi services
>>>>>>> communicate between endpoints in different bundles.
>>>>>>> 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

View raw message