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]
