Ah yes, I see. I wasn't actually aware of START_TRANSIENT before, and a lot of head scratching in this area was how to cope with bundle state between invocations. Thanks.
On Tue, May 14, 2013 at 2:43 PM, Neil Bartlett <[email protected]> wrote: > I think that as an alternative approach to using start levels, you > could use transient starting. > > If (a) the management agent is the only bundle that ever starts > bundles besides itself, and (b) it always starts them transiently, > i.e. with Bundle.START_TRANSIENT, then you can be sure the management > agent will be the only bundle running after a framework restart. > > Neil > > On Tue, May 14, 2013 at 2:39 PM, Dan Gravell <[email protected]> > wrote: > > Gotcha, thanks. > > > > > > On Tue, May 14, 2013 at 2:38 PM, Richard S. Hall <[email protected] > >wrote: > > > >> > >> On 5/14/13 09:35 , Richard S. Hall wrote: > >> > >>> On 5/14/13 09:24 , Dan Gravell wrote: > >>> > >>>> Thanks Richard. > >>>> > >>>> Are start levels not... "bad"... from a conceptual point of view? Or, > in > >>>> this case, where start levels are used to separate "layers" (the > >>>> management > >>>> layer from the application layer) are they deemed ok? > >>>> > >>> > >>> This is pretty much why start levels exist, but regardless, we are > >>> talking about restarting the JVM because you have bundles that won't > >>> behave, so I think adding start levels doesn't really further soil the > >>> situation. :-) > >>> > >> > >> To further clarify, start levels are not intended as a poor man's > approach > >> to ordering bundle start up, since you shouldn't care about the order in > >> which bundles start. Using start levels for coarse grained "mode" > >> management is not unreasonable, but you shouldn't do much more than > that. > >> > >> -> richard > >> > >> > >> > >>> -> richard > >>> > >>> Dan > >>>> > >>>> > >>>> On Tue, May 14, 2013 at 2:07 PM, Richard S. Hall < > [email protected] > >>>> >wrote: > >>>> > >>>> The simplest approach is once you decide some sort of restart is > needed, > >>>>> just stop the framework JVM and have your launcher relaunch it in > >>>>> "update > >>>>> mode" which would be a low start level in which no bundles but your > >>>>> "management" bundle can execute. > >>>>> > >>>>> In this mode, you know no other bundles have started, so your > management > >>>>> bundle can do whatever updates it wants, call refresh, then change > the > >>>>> start level to enter normal operating mode when it is done. > >>>>> > >>>>> -> richard > >>>>> > >>>>> > >>>>> On 5/14/13 07:17 , Dan Gravell 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 > >>>>>> > >>>>>> > >>>>>> > ------------------------------****----------------------------**--**--------- > >>>>> > >>>>> To unsubscribe, e-mail: users-unsubscribe@felix.**apac**he.org< > http://apache.org> > >>>>> <users-unsubscribe@**felix.apache.org< > [email protected]> > >>>>> > > >>>>> For additional commands, e-mail: [email protected] > >>>>> > >>>>> > >>>>> > >>> > >> > >> > ------------------------------**------------------------------**--------- > >> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org< > [email protected]> > >> For additional commands, e-mail: [email protected] > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
