Hi Claus, Thanks a lot. Adding *managementNamePattern="#name#"* to <camelcontext> in blueprint XML seems to click.
This resolved the 2 issues with both re-deployment of the same bundle & also the load-balancing issue when the other VM's acquire the trigger & look up the camel context. We still have 1 pending issue that I reported: Sharing scheduler across camelcontexts with clustered quartz.. a) If we expose the SchedulerFactory as a OSGI service and refer to the same Scheduler Instance across the blueprint bundles (to control the number of Quartz DB accesses): The CamelJob class gets uninstalled when we undeploy 1 route bundle. The rest of the quartz route bundles also stop firing, once we have undeployed 1 camel-quartz2 bundle: 'Caused by: java.lang.ClassNotFoundException: Unable to load class org.apache.camel.component.quartz2.CamelJob by any known loaders.' This is not a blocker, but a performance issue. Appreciate any help in resolving the above issue, as well. Thanks, Lakshmi -- View this message in context: http://camel.465427.n5.nabble.com/Quartz-job-data-deletion-in-clustered-quartz2-tp5757508p5758277.html Sent from the Camel - Users mailing list archive at Nabble.com.
