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