2 Replies Latest reply on May 27, 2010 2:40 AM by bosschaert

    OSGi Start Level Service

    bosschaert

      I started looking at the OSGi Start Level Service and have implemented something that is pretty close to passing the TCK (there's one failure thats related to lifecycle synchronisation). Before finishing it off, I'm looking for some feedback, maybe there are better ways to do things...

       

      So first of all, one fairly big change is that OSGiBundleState.start(int options) now doesn't always start the bundle. It only starts the bundle if the current start level >= the start level of the bundle. Otherwise it just marks the bundle as to-be-started and it might start it later when the start level reaches the level this bundle has.

       

      When the framework starts up, in the OSGiBundleManager.startFramework() it let's the framework increase its start level until it reaches the desired InitialBundleStartLevel, after the AutoInstall plugin had a chance to load its initial bundle set.

      {code}StartLevelPlugin startLevel = getPlugin(StartLevelPlugin.class);

      // Call sls.increaseStartLevel() which is synchronous because we need to wait

      // until the start level is reached

      startLevel.increaseStartLevel(startLevel.getInitialBundleStartLevel());{code}

       

      For the rest, the Start Level Service functionality is implemented by the StartLevelImpl which implements the OSGi Start Level API. It contains async methods to change the framework start level as well as to change the start level of a bundle. It also has a synchronous API for the setting the Start Level which is only used internally when the framework boots up. Oh, and I enhanced the AbstractBundleState to hold the actual start level for this bundle.

       

      BTW I've commented the async executor out for the moment and turned it into a sync executor, but that's only temporarily...

       

      Full details can be found in the attached diff file...

       

      Comments appreciated, David

        • 1. Re: OSGi Start Level Service
          alesj

          Just to link the two related forum posts: http://community.jboss.org/thread/4867

          RUN LEVEL/PERSISTANCE

          This stuff should be implementated on top  of the profile service within jboss,
          but we might want to provide vanilla implementations of this for standalone usage?

           

          The asynch issue

          BTW I've commented the async executor out for the moment and turned it into a sync executor, but that's only temporarily...

          is sympton of what's described here

          LOCKING

          There is a requirement in the spec that when somebody is  controlling the lifecycle
          the bundle should be locked. Other requests  on the bundle, whether lifecycle or
          service operations should wait.
          I  haven't implemented this since this is also an outstanding item on the
          jboss  deployment layer and will need to play nicely with that to avoid  deadlocks.

          This should be handled generically at Deployers level -- https://jira.jboss.org/browse/JBAS-5328.

          • 2. Re: OSGi Start Level Service
            bosschaert

            Given Emanuel's response re the Profile Service (see OSGi/MC Bundle todos) I am concluding that we continue the way we are going now with the Start Level Service... Agree?