12 Replies Latest reply on Jun 13, 2005 3:12 PM by Adrian Brock

    OnDemand + another animals

    Adrian Brock Master

      I've added support for different deployment modes to the controller.

      * DISABLED - The context does not progress beyond the initial "Not Installed".
      * MANUAL - Initially the state is "Not Installed" however the required state
      can be changed with controller.change(ControllerContext, ControllerState)
      * AUTOMATIC - Similar to manual except the initial requested state is "Installed"
      * ON_DEMAND - The context remains at "Not Installed" until somebody introduces a dependency on it. The requested state is then changed to "Installed".

      My main motivation for doing now this is the JMX ServiceController uses the MANUAL
      approach (even if it looks automatic because the SARDeployer drives it), whereas IOC
      uses the AUTOMATIC approach.

        • 1. Re: OnDemand + another animals
          Adrian Brock Master

          There is no "OnUnDemand", i.e. automatically removing an unreferenced
          bean when its dependencies are undeployed.

          This is mainly because I don't want the OnDemand bean to bounce when its only
          dependee is redeployed.
          This will change when I add support for more direct/atomic redeploy.

          • 2. Re: OnDemand + another animals
            Adrian Brock Master

            Do we need any other modes? Most of the usecases I can think of
            can be done with these primitives.

            The only additional feature I plan to support is the "registry" type of OnDemand.
            e.g. jms queue uses OnDemand jms destination manager which not only bootstraps
            the destination manager (if not done so already)
            but also does manager.register/unregisterDestination() as they are undeployed.

            Making this a first class notion removes the need for this boiler plate code in every
            service and also allows extra semantics to be placed at this "JoinPoint" since it is described
            to the controller/microcontainer.

            • 3. Re: OnDemand + another animals
              Scott Stark Master

              What is the correlation with these states and any management exposure, or is that an arbitrary aspect that depends on the service configuration?

              • 4. Re: OnDemand + another animals
                Adrian Brock Master

                Can you repeat the question in English :-)

                Let me explain the recent changes in one place...

                I have changed the controller along the lines mentioned in this thread:

                This allows different context models to be plugged into the same controller
                and take part in the same lifecycle, i.e. dependencies
                Currently, there are two models envisioned
                1) The new BeanMetaData from the pojo microcontainer
                2) The "ServiceContext" from the jmx microcontainer

                It is left to each model to interpret what happens during the different state
                transfers, though they have similar meanings across the models:
                NOT_INSTALLED - the controller knows about the context
                DESCRIBED - the model has examined the metadata
                INSTANTIATED - the target is constructed
                CONFIGURED - the target is configured (setters invoked)
                CREATE - the create method is invoked
                START - the start method is invoked
                INSTALLED - the target is enabled for "external" use
                There is a corresponding reverse set of states.

                The states are also pluggable, i.e. you can insert new states in the Controller,
                though existing models will NOOP the state transfer if they don't understand it.

                I have only envisioned linear state models (with install/uninstall callbacks)
                at the moment, though a graph might also be possible, if more complicated,
                should a usecase demand it.

                On top of this, we have the MODE which is the discussion in this thread.
                The current JMX model has no such notion (everything is MANUAL
                with the AUTOMATIC behaviour an illusion provided by the deployers).

                I plan to retrofit the MODE into the JMX model for deployment/management
                i.e. at least the ServiceController, ServiceMBean and -service.xml.

                Doing the other deployers will take more work since their xml is not always
                simply related to the MBeans they control.

                • 5. Re: OnDemand + another animals
                  Scott Stark Master

                  Got it. The question was concerning the existence of the pure jmx mbean in relation to the ServiceContext integration, as well as the desire to expose a management aspect for a BeanMetaData.

                  With a fixed state model with explicit methods, these methods are the join points for the introduction of adding the management aspect. With a pluggable state model, where is this defined?

                  • 6. Re: OnDemand + another animals
                    Adrian Brock Master

                    The management advice (I think you mean advice/interceptor by aspect?)
                    would need to introduce the additional JMX operations

                    target.setControllerState(state) -> controller.change(context, state)
                    target.setControllerMode(mode) -> context.setMode(mode)

                    Just like ServiceMBeanSupport does now with the redirect through the
                    Otherwise, you can always manage contexts through the controller directly.

                    • 7. Re: OnDemand + another animals
                      Scott Stark Master

                      I'm not following the ServiceMBeanSupport. Maybe there should be another thread on aspects like mangement should be integrated into the lifecycle as I have another question on the MODE behavior which I don't want to pollute with endless sidetracks.

                      • 8. Re: OnDemand + another animals
                        Scott Stark Master

                        So I think another quasi-mode is OnDemandIfRequired. The usecase exists today between the ejb-deployer and the dynamic-classloading-service. If a dynamic-classloading-service is configured for use in any mode, the ejb-deployer should have an optional dependency on it. This means that if the dynamic-classloading-service exists and could become avaialble, add a dependency between ejb-deployer and dynamic-classloading-service. If there is no usable dynamic-classloading-service either because it does not exist or is disabled, do not add a dependency.

                        The OnDemandIfRequired mode would be OnDemand only if the dependents are not optional. In the ejb-deployer/dynamic-classloading-service case, I probably really would want just OnDemand semantics.

                        I'm not clear that OnDemandIfRequired is useful, but the optional dependency certainly is. Is that a notion that already exists?

                        • 9. Re: OnDemand + another animals
                          Adrian Brock Master


                          I know what you are trying to do, but I'm not sure how it could be made to work
                          in a dynamic environment.

                          EJBDeployer isDeployed and started (ifRequired wasn't resolved)
                          EJB deployed
                          DynamicClassLoading is deployed

                          Oops we are in the wrong order so the EJB wasn't processed for DynamicClassLoading.

                          This isn't really a dependency, more of an "optional dynamic plugin" that will require
                          the service accepting the plugin to do extra work.

                          • 10. Re: OnDemand + another animals
                            Adrian Brock Master

                            Maybe this could be made to work with the registry stuff I described earlier.
                            Something like (this is just thinking out loud):

                            <bean class="EJBDeployer">
                             <property name="dynamicClassLoading">
                             <plugin bean="DynamicClassLoading" register="addDeployer" unregister="removeDeployer"/>

                            "plugin" works like "inject" except it doesn't make the EJBDeployer wait for the DynamicClassLoading.
                            "register" is the hypothetical "registry" processing from earlier.

                            So when DynamicClassLoading is available it does

                            The ejbDeployer and dynamicClassLoading would still need some callback
                            protocol to do their work.
                            i.e. process earlier deployments and add new ones

                            • 11. Re: OnDemand + another animals
                              Scott Stark Master

                              So this gets back to the notion of knowing the existence of a component configuration at some point in the server lifecycle due to a static/deterministic configuration. The usecase I want is a static configuration one. There is a dependency injection of the DynamicClassLoading plugin, ONLY if there is a supplier of this service. If the server has been configured to not include a DynamicClassLoading, then there should be no dependency and obviously there will no injection.

                              This is not a relationship I can specify between truly dynamic services in a meaningful way due to the "what do I do now" interaction between the DynamicClassLoading and EJBDeployer that you describe.

                              There is nothing wrong with supporting such an injection sematic such that if a provider of the DynamicClassLoading plugin shows up, it will be used for subsequent deployments.

                              What I was looking for was more of a declarative dependency that allows one to know that at some point in time when the mc configuration has reached some known state (t=0 for a purely static configuration, could be latter if configuration is pulled from another source), there either is a DynamicClassLoading provider and a dependency is needed to ensure all ejb deployments have a DynamicClassLoader, or there is no such provider and no ejb deployment support dynamic class loading.

                              • 12. Re: OnDemand + another animals
                                Adrian Brock Master

                                I never updated this thread with the real answer to this problem.

                                Basically, what you need is a policy object that can be injected. Something like:

                                <bean name="RemoteCL" class="whatever"/>
                                <bean name="EJBDeployer" ...>
                                 <property name="RemoteCL"><inject name="RemoteCL"/></property>
                                or even better?....
                                <bean name="MyEJB" class="org.jboss.ejb.Container">
                                 <property name="RemoteCL"><inject name="EJBDeployer" property="RemoteCL"/></property>

                                Then what you can do is have RemoteCL be defined as either a Null
                                implementation or a real implementation.

                                If you change the implementation of RemoteCL by redeploying its dds
                                it will automatically restart the EJBDeployer/MyEJB with the new config.

                                You don't need the notion of optional, you just need a placeholder that has
                                a Null/NOOP implementation.