4 Replies Latest reply on Jul 2, 2007 12:12 PM by Adrian Brock

    In callback

    Adrian Brock Master

       

      "bill.burke@jboss.com" wrote:
       <bean name="StructuralDeployers" class="org.jboss.deployers.vfs.plugins.structure.VFSStructuralDeployersImpl">
       <!-- Accept any implementor of structure deployer -->
       <incallback method="addDeployer"/>
       <uncallback method="removeDeployer"/>
       </bean>
      



      So the incallback means that any bean that implements the interfaces of VFSStructuralDeployersImpl will automatically incur an addDeployer(this) call on the StructuralDeployer's bean? Or the parameter type of the addDeployer method?


      It is the parameter type of the methods.


      incallback is a HORRIBLE name for this. Please define something that is easier to understand. Thanks.


      I agree. But I don't really care what it is called, I care what does.
      Ales, maybe you can come up with a better name, e.g.
      installCallback and uninstallCallback?

        • 1. Re: In callback
          Adrian Brock Master

          Ales replied.

          "adrian@jboss.org" wrote:

          It is the parameter type of the methods.


          incallback is a HORRIBLE name for this. Please define something that is easier to understand. Thanks.


          I agree. But I don't really care what it is called, I care what does.
          Ales, maybe you can come up with a better name, e.g.
          installCallback and uninstallCallback?


          Just writing response myself. :-)
          Yup I was thinking of something better, but everything looked too long.
          Bill, any (short) suggestions?

          • 2. Re: In callback
            Bill Burke Master

             

            "adrian@jboss.org" wrote:
            Ales replied.

            "adrian@jboss.org" wrote:

            It is the parameter type of the methods.


            incallback is a HORRIBLE name for this. Please define something that is easier to understand. Thanks.


            I agree. But I don't really care what it is called, I care what does.
            Ales, maybe you can come up with a better name, e.g.
            installCallback and uninstallCallback?


            Just writing response myself. :-)
            Yup I was thinking of something better, but everything looked too long.
            Bill, any (short) suggestions?


            BTW, I hate this approach. The install/uninstall syntax was better because it was more readable. At least you knew what was going on. Now you have to guess/read dig deep into the documentation to figure out what is going on.

            • 3. Re: In callback
              Ales Justin Master

               

              "bill.burke@jboss.com" wrote:
              Now you have to guess/read dig deep into the documentation to figure out what is going on.


              It's a simple callback.
              I don't think it can get more 'natural' than this.
              You don't need any sophisticated documentation.
              It's the same thing as if you are aware that install exists, you can also be aware that a callback will be issued. :-)

              • 4. Re: In callback
                Adrian Brock Master

                This callback is just an IOC version of something you can do with OSGi
                (or even the old JMX notifications).

                In OSGi/JMX you can listen to services appearing and disappearing
                and do work on them, e.g.

                public void [un]registerNotification(Event event)
                {
                 if (event.getTarget() instanceof Deployer)
                 [un]register();
                }
                


                All the [un]installCallback is doing is removing the need to write the notification
                handling and wiring yourself.

                Actually, it is slightly more complicated, because you can choose the event
                to be a true dependency (i.e. there must be at least N deployers -most likely 1)
                or optional (I don't care if there are no deployers, deploy me anyway)
                through the cardinality.

                Its probably easier to understand in its alternate form, i.e. as an injection
                of a collection of all implementations of a specific type.

                e.g. intead of, give me a DataSource
                @Inject
                public void setDataSource(DataSource ds);
                


                it is give me all DataSources
                @Inject
                public void setDataSources(Collection<DataSource> all);