Sergey, I agree on Guillaume remark. We should improve what we have in camel project instead of creating a new component. There is a new one "direct-vm" which has been created in camel 2.10 (camel-core) to support communication over camelContext when the camel routes runs in the same JVM. Personally I would prefer that we register (like in NMR) the endpoints in the OSGI Registry (= Global registry) and improve camel to also perform a lookup (with or without filter) in this registry to facilitate communication between bundle in a thread safe and transactional compatible way.
Regards, Charles 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 > >> > >> > >
