+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
