Hi James,
<reference>s are perfect if you have a single processor, if you have more than
one processor that may come and go you
will have to write custom code to publish to all of these processors.
The main goal I was trying to achieve is to send an exchange to multiple osgi
endpoints and to load balance between multiple
osgi endpoints which can be published at any time, so their URIs are not known
at the deployment time.
The simple example is publishing messages to multiple systems.
Here is the route in the producing bundle:
from("direct:start").to("osgi:multicast:consumer")
In the consuming bundle 1 you declare the route to process the exchange like
this
from("osgi:consumer").process(processorA);
If after the time you would like to subscribe the bundle B to the same
exchanges, the only thing you have to do is to
deploy another bundle with route like this:
from("osgi:consumer").process(processorB);
Of course you can use jms topics or something like this but I suppose osgi
component is more lightweight and does not involve
additional software. Moreover jms does not support aggregation strategies so
you will have to complicate your route
with aggregate eip. For multicasting to multiple bundles you can also involve
"vm" endpoints, but they don't support
synchronous multicasting, aggregation strategies, stopping on failures, etc.
> What exactly are you trying to achieve? You just want to try to talk
> to OSGi services? Can't you just do that with <reference>s and
> beanRef?
> On Tue, May 22, 2012 at 1: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
>>
>>
--
Best regards,
szh mailto:szh.s...@gmail.com
