Hi Raul, a code sample? I need to create one again :) Cause I don't have access to the original code anymore it's been more than 2.5 Years ago. I know what you are talking of, we have a similar saying in Germany ;) Shooting sparrows with cannons. Never the less I'm gonna create a sample asap.
Basically it's been a SEDA service endpoint also registered as a OSGi Service. The Other route referenced it and only did sent to this SEDA endpoint. So maybe that's the reason it did work :) (to my knowledge it still works) regards, Achim 2013/2/10 Raul Kripalani <r...@evosent.com> > Hi Achim, > > Would you mind explaining this approach a little bit? A code sample would > be awesome. > > Until now we have suggested folks to use NMR, but installing 7 SMX bundles > just to achieve inter-bundle communication seems like "shooting flies with > a bazooka" (like we say here in Spain :D). > > I remember a thread sometime ago about creating a component to link any two > routes across bundles via OSGi services, but don't know what happened with > the idea thereafter. > > Regards, > Raúl. > On 8 Feb 2013 21:02, "Achim Nierbeck" <bcanh...@googlemail.com> wrote: > > > Hi, > > > > The routes in your bundles are all managed by the camel-core bundle. > > Since you updated one of it the "old" reference still exists for the core > > bundle. > > So after updating a bundle containing routes you also need to refresh the > > core bundle. > > > > Another way to work around this, or better something that did work > already > > for me, I registered a SEDA endpoint as service. This way I was able to > > share a endpoint between two bundles as communication bridge. > > > > Regards, Achim > > > > sent from mobile device > > Am 08.02.2013 11:30 schrieb "SteveC" <steve.chap...@nz.unisys.com>: > > > > > I have 2 camel routes, each deployed in separate bundles to Fuse ESB > > > (7.0.0.fuse-061). > > > > > > Route 1 accepts text via HTTP and send it to a vm queue, e.g. <to > > > uri="vm:TestQ"/> > > > > > > Route 2 accepts input from the vm queue, e.g.. <from uri="vm:TestQ"/>, > > and > > > logs a msg. > > > > > > Each route is deployed in a Karaf feature and they function correctly > on > > > initial deployement, i.e. I can send a msg via HTTP to route1 and it is > > > passed to route 2 via the vm queue. > > > > > > When I use the Karaf console Bundles page to update the bundle for > either > > > or > > > both bundles they stop and restart with no apparent errors but from > then > > on > > > the vm queues are disconnected, e.g. I can send a msg via HTTP to > route1 > > > and > > > it sends the msg to the vm queue, but route 2 never sees the msg arrive > > > from > > > the vm queue and eventually the exchange times out in route 1 (using > > InOut > > > MEP). > > > > > > Once in this state the only way to get the routes to link via the vm > > queue > > > again is to either bounce Fuse ESB or to uninstall/install the > associated > > > features. > > > > > > I've tried adding some options to see if behaviour will change but no > > joy - > > > tried pollTimeout and concurrentConsumers. > > > > > > The only reason for the bundle update is to bounce in new > configuration, > > it > > > is frustrating having to bounce Fuse ESB just to update the config for > a > > > single bundle. > > > > > > I've tried replacing the VM component with JMS i.e. using JMS queues, > and > > > the behaviour is as expected without any problem. > > > > > > Advice anyone? > > > > > > Thanks > > > Steve > > > > > > > > > > > > -- > > > View this message in context: > > > > > > http://camel.465427.n5.nabble.com/VM-Queues-Disconnected-after-Karaf-Bundle-Update-tp5727205.html > > > Sent from the Camel - Users mailing list archive at Nabble.com. > > > > > > -- Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead OPS4J Pax for Vaadin <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project Lead blog <http://notizblog.nierbeck.de/>
