On Tue, Dec 9, 2014 at 8:16 AM, Richard S. Hall <he...@ungoverned.org> wrote: > On 12/9/14 01:55 , Felix Meschberger wrote: >> >> Hi >> >>> Am 09.12.2014 um 03:02 schrieb Richard Hall <he...@ungoverned.org>: >>> >>> On 12/8/14 20:47 , Benson Margulies wrote: >>>> >>>> On Mon, Dec 8, 2014 at 8:34 PM, Richard S. Hall <he...@ungoverned.org> >>>> wrote: >>>>> >>>>> On 12/8/14 18:07 , Benson Margulies wrote: >>>>>> >>>>>> FrameworkStartLevel#setStartLevel takes listeners, which looks really >>>>>> useful. Can I call it instead of Framework#start? >>>>> >>>>> They don't do the same thing, but certainly you can use either... >>>> >>>> That's what I'm trying to sort out. To be perfectly clear about my >>>> ignorance, I don't understand what the FrameworkStartLevel method is >>>> for if it's not another way to express the Framework method. >>>> >>>> Here's what I have working: >>>> >>>> 1. framework.init(); >>>> 2. obtain default bundle start level from FrameworkStartLevel >>>> 3. installBundle all bundles >>>> 4. set start level for each bundle by adapting to a BundleStartLevel >>>> 5. start all bundles >>>> 6. framework.start >>>> >>>> So, where would FrameworkStartLevel#setStartLevel fit into all this? >>>> Is it only useful if I need to change the start level after >>>> framework.start()? >>> >>> Yeah, it is pretty much only useful after you activate the framework >>> (i.e., call start()). Although, after a quick look, I'm not 100% certain >>> what the Felix framework implementation will do if you call setStartLevel() >>> before calling start()… >> >> My interpretation is, that the init() method sets the StartLevel service >> up and then calling setStartLevel instead of Framework.start() would >> probably start the framework except: The framework STARTED event would not >> be sent ! > > > Yes, that was sort of my interpretation of looking at the code too, but I'm > not convinced that that is the correct behavior.
I'm not interested in subverting the API, but rather understanding the thought process of the structure. The spec is unclear about what happens if you set the 'begin' level to 0. Would that cause start() to leave the start level alone? In any case, it seems to me to be a bit of an asymmetry that the one method takes 'for the duration' listeners and the other doesn't, and my idea about using start level 2 is an unambiguous way to take advantage of those listeners. Or, add a listener that bops a countdown latch, call start(), wait on the latch. > > -> richard > >> >> It would really stick to the original intent, as I read it: Use >> Framework.start() to start the framework and use >> FrameworkStartLevel.setStartLevel to change the current start level. >> >> Regards >> Felix >> >>> -> richard >>> >>>> >>>> >>>> >>>> >>>>> -> richard >>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >>>>> For additional commands, e-mail: users-h...@felix.apache.org >>>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >>>> For additional commands, e-mail: users-h...@felix.apache.org >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >>> For additional commands, e-mail: users-h...@felix.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >> For additional commands, e-mail: users-h...@felix.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
