On Fri, Jun 22, 2012 at 10:41 PM, Sergey Zhemzhitsky <szh.s...@gmail.com> wrote:
> Hello Guillaume,
>
> I suppose static method to retrieve consumers that can be filtered by a custom
> expression will be quite enough.
>
Yeah that may be a good idea and fairly easy to implement.
The regular direct component could in theory also support this, but I
guess direct-vm makes the most sense only, as its cross CamelContext
communication.
The filter expression could also be defined in the uri, if we want to
consider that, though the foo name would then become a dummy? Or would
it be to confusing if the name is a filter itself
.to("direct-vm:dummy?filter=someFilterStuffHere")
.to("direct-vm:someFilterStuffHere")
> Regards,
> Sergey
>
>
>> On Fri, Jun 22, 2012 at 6:33 AM, Sergey Zhemzhitsky <szh.s...@gmail.com>
>> wrote:
>>> Hello, guys,
>>>
>>> I agree that if the camel-core could be enhanced to achieve easy
>>> cross-context
>>> communication in the single JVM it would be fine.
>
>> Claus committed the direct-vm component recently which is part of 2.10:
>> http://camel.apache.org/direct-vm.html
>
>>> In that case I would not tire the core to OSGi anyhow to be really
>>> environment-independent.
>>> I suppose that camel context could be published into the JNDI to be
>>> retrieved at some time
>>> lately to discover consuming endpoints. Thus we can achieve the similar
>>> behavior in different
>>> environments and
>>>
>>> from("foo:bar").recipientList(osgiServices("myldapfilter"))
>>>
>>> would become
>>>
>>> from("foo:bar").recipientList(vm("myfilter"))
>>>
>
>> Atm, the direct-vm queues are not really accessible afaik, so we may
>> need to enhance the direct-vm slightly to allow retrieving the set of
>> registered consumers (adding a static getRegisteredConsumers on the
>> component should be sufficient). Those are mapped by the path
>> component of the consumer uris, so it already provides some kinda of
>> tree based structure. If that's sufficient, we would just need a
>> simple expression that would filter them based on some regular
>> expression maybe.
>
>>>
>>> Regards,
>>> Sergey
>>>
>>>
>>>
>>>> Agree, I think that enhancing the existing could achieve this.
>>>
>>>> Regards
>>>> JB
>>>
>>>> On 06/21/2012 08:51 AM, Guillaume Nodet wrote:
>>>>> 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
>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>
--
Claus Ibsen
-----------------
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
