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