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] > >
