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

Reply via email to