4 Replies Latest reply on Jan 28, 2006 12:45 PM by Adrian Brock

    Convenience classes on top of MC

    Dimitris Andreadis Master

      Would it make sense to create convenience classes on top of MC, e.g. scheduler wrappers on top of jdk timers or quartz ? The other frameworks have that.

      And if so, where in the code this would go? Somewhere outside the 'kernel' module (a new module, or the varia (dumping ground)) ?

        • 1. Re: Convenience classes on top of MC
          Adrian Brock Master

          Yes it belongs outside the kernel. Unless the problem involves general
          configuration or the dependency/state mechanism it is outside the realm of the MC.

          I'm not sure what you plan to add?

          e.g. when I've done the "generic install" you will be able to do something like
          the following:

          <bean name="Timer" class="javax.util.Timer"/>
          
          <bean name="MyTask" class="com.acme.MyTimerTask">
           <install bean="Timer" method="schedule">
           <parameter><this/></parameter>
           <parameter>1000</parameter> <!-- start in 1 second -->
           <parameter>10000</parameter> <!-- every 10 seconds -->
           </install>
           <uninstall method="cancel"/>
          </bean>
          


          • 2. Re: Convenience classes on top of MC
            Dimitris Andreadis Master

            Yes, something like that.

            So with install a bean can call arbitrary methods on other bean when installed (startup lifecycle complete); sort of a lifecycle callback after "start" but on other beans, nice!

            I suppose uninstall is initiated before "stop"?

            Does uninstall bind to the same bean (or should be)

             ...
             <uninstall bean="Timer" method="cancel"/>
            

            Also, can I have multiple installs/unistalls in the same bean?

            We can avoid a lot of wrappers with this.

            • 3. Re: Convenience classes on top of MC
              Adrian Brock Master

               

              "dimitris@jboss.org" wrote:
              Yes, something like that.

              So with install a bean can call arbitrary methods on other bean when installed (startup lifecycle complete); sort of a lifecycle callback after "start" but on other beans, nice!


              Except it doesn't actually exist yet. :-)


              I suppose uninstall is initiated before "stop"?


              Yes.


              Does uninstall bind to the same bean (or should be)
               ...
               <uninstall bean="Timer" method="cancel"/>
              


              No bean="blah" means invoke on self. What you wrote cancels the timer
              rather than stopping the task.


              Also, can I have multiple installs/unistalls in the same bean?

              We can avoid a lot of wrappers with this.


              Yes. The installations will be done in order and uninstalled in reverse order.