camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <>
Subject Re: Camel OSGi services component
Date Thu, 21 Jun 2012 06:27:50 GMT
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...


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 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,
> dynamism, priorities, etc.
> It would be nice if direct-vm allowed to configure pub-sub with all the options of multicast
> 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,  <> wrote:
>>> Hi gurus,
>>> Recently  I've  published  camel  component that uses OSGi services to
>>> 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

Guillaume Nodet
FuseSource, Integration everywhere

View raw message