Ok that sounds interesting. I will definitely look into these start levels, thanks!
One question though. If we have some time consuming work to do after Felix has started, but before we enter NORMAL mode, wouldn't the File Install bundle still start during that time consuming work? It is important to us that it never starts before we enter NORMAL mode, even if it might take ten seconds after the last system bundle was installed in INITIALIZE mode before we finally enter NORMAL mode. I am currently looking into uninstalling the File Install bundle when we shutdown, so it will be removed from the cache once we startup again, but the problem I have with that is that I fear it may not be as robust. if the server would stop without going through the shutdown code in the intended manner (crash, power outage etc) the File Install bundle would still be lingering in the cache and cause problems on the next startup. A possible solution would be to set some flag after the shutdown code has finished and check that flag again on startup, clearing the bundle cache if the shutdown code was not completed correctly. But this all adds to complexity of course. Maybe I could combine both approaches. Is there some way to set a startlevel manually? Something like this: Server.enterNormalMode(); Felix.setStartLevel(3); Or perhaps by using the ServiceTracker we could signal the File Install bundle when it's good to go? -Stijn -----Original Message----- From: Karl Pauls [mailto:[email protected]] Sent: donderdag 22 april 2010 11:05 To: [email protected] Subject: Re: Prevent specific cached bundle from starting It sounds to me like what you want to do is to look into startlevels. Basically, all your bundles from your INITIALZE mode should be in one startlevel and the file install bundle in a higher level. That way, all your bundles will be started before the file install bundle gets started (and that will be the case for the startup with an exisiting cache as well). regards, Karl On Thu, Apr 22, 2010 at 10:49 AM, Stijn de Witt <[email protected]> wrote: > Hi all, > > > > I was wondering if it is possible to prevent a specific cached bundle > from starting when Felix starts? > > > > We have started using OSGi and Felix in our existing product a while ago > but still are coming to grips with it. One thing that we had some > trouble with (and had implemented badly) is the use of the Felix bundle > cache. > > We initially always cleared the bundle cache before starting Felix and > then had Felix install some system bundles by setting the property > "felix.auto.start.1" to a list of bundles to be started. We then did > some application specific startup logic and only when that was done > would we install the Felix File Install bundle 'manually' with a call to > BundleContext#installBundle. > > > > Unfortunately this degraded our startup performance. An OSGi expert > pointed out to us that this is not very efficient and that the bundle > cache is meant to (be able to) survive between shutdown and startup, so > we are now refactoring our code to use this feature. It is here that we > run into the problem. > > > > Basically startup of our server consists of two phases: INITIALIZE mode > and NORMAL mode. During initialize mode the system bundles should be > installed and started and any 'user' bundles that were already installed > and running before the server was stopped should resume. Then, when we > enter NORMAL mode, the File Install bundle should be installed and > started and monitor the bundle deploy folder for new, changed or removed > user bundles. However, when we start Felix with the File Install bundle > in the cache, that starts right away and immediately begins installing > 'user' bundles when we are still in INITIALIZE mode, causing havoc. > > > > So what I want is, just before calling Felix.start, remove the File > Install bundle from the cache so we can install it manually after we > entered the NORMAL mode. > > > > Is that possible? Or even the right way to go about it? Or is there some > smarter approach we could take? > > Any advice would be greatly appreciated. > > > > Thanks for a great open source project! > > > > -Stijn > > > > -- Karl Pauls [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
