1 2 3 Previous Next 37 Replies Latest reply on Nov 23, 2009 8:46 AM by adrian.brock Go to original post
      • 30. Re: Service integration with MC

        You should also have some

        (un)getTarget(ServiceTracker me)
        


        methods when the caller doesn't have a specific ControllerContext but it does
        know its ServiceTracker. e.g. The OSGi api is at the deployment level
        by passing in the Bundle to getService(Bundle).

        • 31. Re: Service integration with MC
          alesj

           

          "adrian@jboss.org" wrote:

          e.g. The OSGi api is at the deployment level
          by passing in the Bundle to getService(Bundle).

          Wouldn't this be DeploymentControllerContext?


          • 32. Re: Service integration with MC
            alesj

             

            "adrian@jboss.org" wrote:
            It should be done on the calls to (un)getTarget()

            // Mixin interface for service tracking
            public interface ServiceTracking
            {
             ...
            
             if (me instanceOf ServiceTracking)
             {
             ServiceTracker otherTracker = me.getServiceTracker();
             if (otherTracker != null)
             otherTracker.incrementUsing(this);
             }
             }
             return result;
            }
            


            The instanceOf ServiceTracking is for backwards compatibilty in case
            some old ControllerContext doesn't know about ServiceTracking.

            I don't get this "instance of"?
            Wouldn't ControllerContext implement this ServiceTracking mixin?

            OK, I guess since you called it mixin, it should be just AbstractControllerContext that impls it.
            But this makes lookup code ugly ... checking every context in metadata if it's ServiceTracking interface.
            Oh well, some copy pasting won't kill me ... :-)

            • 33. Re: Service integration with MC

               

              "alesj" wrote:
              "adrian@jboss.org" wrote:

              e.g. The OSGi api is at the deployment level
              by passing in the Bundle to getService(Bundle).

              Wouldn't this be DeploymentControllerContext?


              But that's just an implementation detail. ;-)

              The actual answer is yes for normal bundles, because they always represent
              top level deployments. OSGi bundles can't have subdeployments.

              But its also not for the SystemBundle which doesn't have a DeploymentUnit, it should use
              the SYSTEM level.

              I can imagine other cases where you might not have a specific ControllerContext but
              you do know what your ServiceTracker is (or something else does and can "hide" the
              link through its own api).

              Or as I described above, you may want to do tracking at subdeployment level.
              The DeploymentControllerContext is no use there because it maps to the top level
              deployment.

              DeploymentControllerContext.getScope() -> APPLICATION scope
              DeploymentUnit.getTopLevel().getScope() -> APPLICATION scope
              (Sub)DeploymentUnit.getScope() -> DEPLOYMENT scope

              So you can see that using the implement detail actually can give you the wrong answer.
              Because you are writing to the wrong api. ;-)

              • 34. Re: Service integration with MC

                 

                "alesj" wrote:

                I don't get this "instance of"?
                Wouldn't ControllerContext implement this ServiceTracking mixin?


                No, you can't add new methods to a public interface in a stable branch.
                It breaks any code that implements the interface directly rather than using
                the Abstract helper class (users of AbstractControllerContext should get the new methods
                with default implementations like I described above).

                MC-3.0.x would be the time when you can change the public api.

                • 35. Re: Service integration with MC
                  alesj

                   

                  "adrian@jboss.org" wrote:

                  MC-3.0.x would be the time when you can change the public api.

                  Not even for 2.2.x? Which is where I planned this.
                  (I have no intentions of providing this for 2.0.x).

                  • 36. Re: Service integration with MC

                     

                    "alesj" wrote:
                    "adrian@jboss.org" wrote:

                    MC-3.0.x would be the time when you can change the public api.

                    Not even for 2.2.x? Which is where I planned this.
                    (I have no intentions of providing this for 2.0.x).


                    No. Major changes need an update to the major version number.

                    See for example:
                    http://java.sun.com/j2se/1.5.0/docs/guide/versioning/spec/versioning2.html#wp89940

                    Of course, Java breaks its own rules. e.g. the changes to the java.sql interfaces
                    between 1.5 and 1.6 - but then that's really between 5.x and 6.x in Sun's bizarre versioning
                    of java. ;-)

                    • 37. Re: Service integration with MC

                      NOTE: If you did decide to make the next MC release 3.0.x then that would exclude
                      this feature getting backported into JBoss5 since it would be a major change in
                      a stable branch there.

                      1 2 3 Previous Next