Ah yes, well on that subject I can only reiterate what others have said, that the bundle needs to be responsible for its own threads and start/stop them in the BundleActivator appropriately.
Thanks Bruce On 14 May 2013, at 14:02, Dan Gravell <[email protected]> wrote: > Thanks Bruce. The trouble is that calling stop() does not stop all the > threads started by some of the bundles I use, so using start levels isn't > helpful at the part where the bundles are updated. However, it may be > useful for restart to *attempt* to make sure some "bootstrap" bundle is > started first. > > Dan > > On Tue, May 14, 2013 at 12:23 PM, Bruce Jackson <[email protected]> wrote: > >> I'm not sure exactly what you're trying to do, but in the past I'm used an >> embedded Felix instance with a single 'management' bundle running at start >> level 1 which was then able to download and deploy all of the other bundles >> in my system at start levels > 1. >> >> In this setup, all I needed to do was to drop the platform start level to >> 1 which had the effect of calling stop() on all of the installed bundles. >> In this state you can then uninstall and bundles to be updated, then just >> set the start level back up to the default. >> >> On 14 May 2013, at 12:17, Dan Gravell <[email protected]> wrote: >> >>> Hi all. After giving it about a year of tweaks, I'm finally going to give >>> up trying to update my OSGi app in process. The killer is the requirement >>> to stop all threads... for my particular requirements this just isn't >>> feasible. I have to maintain my own forks of projects, some complex (the >>> Lift web framework) and some less so (JNotify) and this just takes too >> long. >>> >>> So I'm putting thought to how I can structure a solution that restarts >> the >>> JVM *at some point*. I am using Felix 'bundlerepository' bundle to >> perform >>> the deployments of bundles. >>> >>> So first, the requirement to stop threads: is this a requirement *before* >>> start(), stop() or update(URL) is called? >>> >>> If it's only something that has to be done before stop() then I _could_ >> do >>> everything I do now, up to when start() is called on each bundle. At that >>> point, I could exit with an exit code and my launcher script checks that >>> and, if it's a known value, restarts the same process. In this case, I >>> would have to re-start the bundles on restart. >>> >>> If threads have to be stopped before the update itself, then I suppose I >>> can download the bundles to a holding area, and have a bootstrap JVM that >>> picks them up and somehow performs the update, and then starts. >>> >>> If anyone has any wisdom or experience of this I would be grateful to >> hear >>> it... >>> >>> Dan >> >> >> >> >> This e-mail is only intended for the person(s) to whom it is addressed and >> may contain CONFIDENTIAL information. Any opinions or views are personal to >> the writer and do not represent those of INQ Mobile Limited, Hutchison >> Whampoa Limited or its group companies. If you are not the intended >> recipient, you are hereby notified that any use, retention, disclosure, >> copying, printing, forwarding or dissemination of this communication is >> strictly prohibited. If you have received this communication in error, >> please erase all copies of the message and its attachments and notify the >> sender immediately. INQ Mobile Limited is a company registered in the >> British Virgin Islands. www.inqmobile.com. >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> This e-mail is only intended for the person(s) to whom it is addressed and may contain CONFIDENTIAL information. Any opinions or views are personal to the writer and do not represent those of INQ Mobile Limited, Hutchison Whampoa Limited or its group companies. If you are not the intended recipient, you are hereby notified that any use, retention, disclosure, copying, printing, forwarding or dissemination of this communication is strictly prohibited. If you have received this communication in error, please erase all copies of the message and its attachments and notify the sender immediately. INQ Mobile Limited is a company registered in the British Virgin Islands. www.inqmobile.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
