1 Reply Latest reply on Feb 10, 2010 9:12 AM by alesj

    ControllerContextPlugin clarification

    thomas.diesler

      In ControllerContextPlugin what is the difference between

       

        /**
          * Get bundle for user tracker.
          *
          * @param user the user tracker object
          * @return bundle state
          */
         AbstractBundleState getBundleForUser(Object user);
         
         /**
          * Get bundle for context.
          *
          * @param context the context
          * @return bundle state
          */
         AbstractBundleState getBundleForContext(ControllerContext context);
      
      

       

      In getBundleForUser, what are valid 'user' objects? What is a 'user'?

      In getBundleForContext, is the context the ControllerContext that is associated with a OSGiServiceState?

        • 1. Re: ControllerContextPlugin clarification
          alesj

          Here we're asking for the actual bundle that is associated with the "user".

          It means that ContextTracker for particular ControllerContext returned "user",

          to be using this particualr ControllerContext.

           

          In OSGi words, some "user" is using OSGi service.

          Now we wanna know the exact bundle this "user" is associated with.

           

          In getBundleForUser, what are valid 'user' objects? What is a 'user'?

          Valid users are other bundles (this is how OSGi tracks usage),

          and other ControllerContexts in generic MC sense (e.g. a bean to whome we inject some OSGi service).

           

          We have a notion of ContextTracker, which is completely generic in a sense of who's actually using ContextTracker's owning ControllerContext.

          You can declare any object to be the user of that ControllerContext, meaning we don't limit ourselves to who can actually use it.

           

          In getBundleForContext, is the context the ControllerContext that is associated with a OSGiServiceState?

          Yes - read above.

           

          In generic MC case, we can only track other beans/services using OSGi services,

          as those other beans/services don't have such explicit api/notion of using-bundle as OSGi does.

          But as this code shows, we can always associate beans/services with some DeploymentUnit or in the worst case system bundle.
          If it's the first, then we "artificially" turn DU into bundle -- which was always the intent if you look into OSGiBundleDeployer's javadoc.