8 Replies Latest reply on Feb 22, 2008 3:30 AM by Ales Justin

    In/Un callbacks should be happening at Install

    Adrian Brock Master

      The In/Uncallbacks were setup to happen at the Configured on the thing being
      registered into, this is the wrong default.

      We shouldn't be installing into a registry until it has had chance to
      go through its lifecycle. e.g. create() can be used to validate configuration is correct
      (no missing or inconsistent properties) and fail if there is a problem.

      Or the registry may need to do extra work before receiving registrations,
      possibly based on the value of two parameters passed during the config stage.

      I've changed the default state to be Installed (this is the "no surprises" setting).
      If somebody wants it to happen earlier, then can always change it in the xml
      or the annotation.

      Further, there were are ZERO tests of changing whenRequired and dependentState
      for the callbacks.

      I created one for changing the dependentState=Instantiated
      (fortunately it works :-), but this obviously needs to be tested more systematically.

        • 1. Re: In/Un callbacks should be happening at Install
          Adrian Brock Master

          Also, related to this, it might be useful if we generalise the install
          to be doable at anytime (well at least from instantiated),
          rather than just when the object is "installed".

          e.g.

          <bean ...>
           <install bean='Registry" method="add" state="Configured">
           <parameter><this/></parameter>
           </install>
          </bean>
          


          i.e. like the incallback, you could add an object to a registry before it has
          completed its lifecycle.

          This is the case for example in some of the classloader stuff I'm doing
          where the "Module" is added to the "ClassLoading" registry for dependency anaylsis
          at "Configured" but it doesn't go through to the 'Install" (creation of the classloader)
          until those dependencies are satisifed.

          Currently I have to use an InstallCallback to achieve this
          (which isn't a big issue except that it would only allow one ClassLoading instance).

          • 2. Re: In/Un callbacks should be happening at Install
            Ales Justin Master

             

            "adrian@jboss.org" wrote:
            Also, related to this, it might be useful if we generalise the install
            to be doable at anytime (well at least from instantiated),
            rather than just when the object is "installed".

            Yup, I though about this once. Probably when doing callbacks, as you could also see that it's a lot similar.

            Kabir's AOP callbacks also allow you to do this. Some more code is required, and pointcut must match the exact bean.
            And it requires AOP. :-)

            I'll push the install execution to a common Action class + add the state attribute.

            • 3. Re: In/Un callbacks should be happening at Install
              Ales Justin Master

              We already have 'state' attribute, which marks the dependent state of the target bean (if there is one configured for install/uninstall).

              if (install.getBean() != null)
               target = controller.getContext(install.getBean(), install.getDependentState());
              

              What sohuld we call the new state attribute, whenRequired to make it consistent?

              Should we allow this just for certain states?
              I would again leave it to the user, since we don't enforce this anywhere else.

              • 4. Re: In/Un callbacks should be happening at Install
                Adrian Brock Master

                I guess using whenRequired makes sense.

                The install and incallback won't work before instantiated unless you
                explicitly pass the target on the controller context when installed into the MC.
                i.e. you are installing a pre-instantiated object.

                For the use of should validate that there is actually something to inject?

                • 5. Re: In/Un callbacks should be happening at Install
                  Ales Justin Master

                   

                  "adrian@jboss.org" wrote:
                  For (install/) the use of (this/) should validate that there is actually something to inject?

                  Since we allow install execution on any InvokeDispatchContext, it boils down to the target context to inform you if it cannot invoke the method.
                  But I think we have pretty good info in those cases.
                  e.g. MBeanServer is gonna complain that the mbean is not yet registered, ReflectionUtils that the target object was null, ...


                  • 6. Re: In/Un callbacks should be happening at Install
                    Ales Justin Master

                    When the installs fail, should we just unwind from the current index?
                    The thing is that uninstalls are different instances, and user can order them differently than the matching installs, or install perhaps even doesn't need to have matching uninstall.
                    But normally they do. :-)

                    So, the only question is, what to do by default - execute all uninstalls or just from the failed install's index?

                    • 7. Re: In/Un callbacks should be happening at Install
                      Adrian Brock Master

                       

                      "alesj" wrote:
                      When the installs fail, should we just unwind from the current index?
                      The thing is that uninstalls are different instances, and user can order them differently than the matching installs, or install perhaps even doesn't need to have matching uninstall.
                      But normally they do. :-)

                      So, the only question is, what to do by default - execute all uninstalls or just from the failed install's index?


                      I'd just execute all the unintalls and ignore errors.
                      But you only need to do that if one of the installs has suceeded.

                      Like you said, install/uninstall are not necessarily symmetric.

                      • 8. Re: In/Un callbacks should be happening at Install
                        Ales Justin Master

                         

                        "adrian@jboss.org" wrote:
                        I'd just execute all the unintalls and ignore errors.
                        But you only need to do that if one of the installs has suceeded.

                        Like you said, install/uninstall are not necessarily symmetric.

                        I've still left a way for users to override the failure behavior, e.g. applying the uninstalls only from the current installs index.
                        But by default we do what quote suggests. ;-)