1 2 Previous Next 26 Replies Latest reply on Jan 17, 2007 11:47 AM by alesj

    bean/mbean integration issue

    starksm64

      I was hoping to be able to reference the jboss-service.xml mbean for the socket remoting transport to register a handler for the ProfileService with it similar to how deployers register with the MainDeployer:

      ...
       <!--
       Add a ProfileService handler to the remoting socket connector
       -->
       <bean name="ProfileServiceInvocationHandler"
       class="org.jboss.aspects.remoting.AOPRemotingInvocationHandler">
       <install bean="jboss.remoting:service=Connector,transport=socket" method="addInvocationHandler">
       <parameter>ProfileService</parameter>
       <parameter><this/></parameter>
       </install>
       <uninstall bean="jboss.remoting:service=Connector,transport=socket" method="removeInvocationHandler">
       <parameter>ProfileService</parameter>
       </uninstall>
       </bean>
      


      however, there is a type conflict showing up:
      12:56:19,930 ERROR [AbstractKernelController] Error installing to Installed: name=ProfileServiceInvocationHandler state=Start
      java.lang.ClassCastException: org.jboss.system.microcontainer.ServiceControllerContext
       at org.jboss.kernel.plugins.dependency.InstallAction.installActionInternal(InstallAction.java:67)
       at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.installAction(KernelControllerContextAction.java:187)
       at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.install(KernelControllerContextAction.java:126)
       at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
       at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:233)
       at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:709)
       at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:430)
       at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:540)
       at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:474)
       at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:274)
       at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:177)
       at org.jboss.deployers.plugins.deployers.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:67)
       at org.jboss.deployers.plugins.deployers.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:42)
       at org.jboss.deployers.plugins.deployers.helpers.AbstractSimpleRealDeployer.deploy(AbstractSimpleRealDeployer.java:53)
       at org.jboss.deployers.plugins.deployer.AbstractSimpleDeployer.commitDeploy(AbstractSimpleDeployer.java:52)
       at org.jboss.deployers.plugins.deployer.DeployerWrapper.commitDeploy(DeployerWrapper.java:156)
       at org.jboss.deployers.plugins.deployment.MainDeployerImpl.commitDeploy(MainDeployerImpl.java:523)
       at org.jboss.deployers.plugins.deployment.MainDeployerImpl.commitDeploy(MainDeployerImpl.java:534)
       at org.jboss.deployers.plugins.deployment.MainDeployerImpl.process(MainDeployerImpl.java:461)
       at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:372)
      ...
      


      To allow for such an interaction, the mbean needs to have a mapping of its ServiceControllerContext to a KernelControllerContext, or ServiceControllerContext and KernelControllerContext need a shared base class that adds a common DispatchJoinPoint notion.

      I can workaround this by moving the legacy remoting mbean to a mc bean (hopefully).


        • 1. Re: bean/mbean integration issue
          starksm64

          The remoting connector could not simply be ported to a mc bean as it does not support its configuration as a pojo. The workaround I came up with was to introduce an mc bean proxy for the connector mbean using factoryClass attribute and the existing org.jboss.mx.util.MBeanTyper factory type class:

           <bean name="ConnectorMBean">
           <!-- MBeanTyper.typeMBean(MBeanServer, ObjectName, Class iface) -->
           <constructor factoryClass="org.jboss.mx.util.MBeanTyper" factoryMethod="typeMBean">
           <parameter><inject bean="JMXKernel" property="mbeanServer"/></parameter>
           <parameter>jboss.remoting:service=Connector,transport=socket</parameter>
           <parameter>org.jboss.remoting.transport.ConnectorMBean</parameter>
           </constructor>
           </bean>
           <!--
           Add a ProfileService handler to the remoting socket connector
           -->
           <bean name="ProfileServiceInvocationHandler"
           class="org.jboss.aspects.remoting.AOPRemotingInvocationHandler">
           <install bean="ConnectorMBean" method="addInvocationHandler">
           <parameter>ProfileService</parameter>
           <parameter><this/></parameter>
           </install>
           <uninstall bean="ConnectorMBean" method="removeInvocationHandler">
           <parameter>ProfileService</parameter>
           </uninstall>
           </bean>
          



          • 2. Re: bean/mbean integration issue

            This was the original intention of the KernelBus notion,
            but the Service model doesn't currently have a "Joinpoint" abstraction.

            I have already asked Ales to go through these actions classes to remove
            the "logic" into delegate classes. I think this falls under that work?

            • 3. Re: bean/mbean integration issue
              alesj

               

              "adrian@jboss.org" wrote:

              This was the original intention of the KernelBus notion,
              but the Service model doesn't currently have a "Joinpoint" abstraction.

              How did you envision KernelBus notion with this issue?

              "adrian@jboss.org" wrote:

              I have already asked Ales to go through these actions classes to remove
              the "logic" into delegate classes. I think this falls under that work?


              You mean plugable 'joinpoint' delegate, regarding what the Context is - KernelControllerC, ServiceControllerC, ...

              Can you create a JIRA task for this issue with some info (assigning it to me)?

              What about http://jira.jboss.com/jira/browse/JBMICROCONT-135?
              This was my first understanding about Service to Kernel abstraction that we talked about. Probably not much to do in this area? I'll still take a look what else can we port to Services.



              • 4. Re: bean/mbean integration issue

                The kernel bus hasn't really had any work done on it.

                The original idea was that it would provide a generic entry point for invocations
                on different contexts, e.g. Properyt/MethodJoinpoints for POJOs
                Attributre/OperationJoinpoints for JMX.

                Its main use would be to replace the Dispatcher (AOP remoting) and
                org.jboss.system.Registry (JBossAS's detyped invokers)
                as a common entry point for named based invocations.

                However, I agreed with Bill about 2 years ago that rewriting AOP and JMX
                to support a common Joinpoint abstraction would be a lot of work.
                If it is to be done at all it would left to a later iteration.

                Scott's idea of adding a "dispatch" abstract to the context api
                would work. In fact, I really want to change the BeanInfo api to support
                this notion like the ClassInfo api already does (i.e. there get/set methods
                on fields and invoke on methods).

                The api would be more like the DynamicMBean api
                where there are methods to get/set Properties/Attributes and invoke on
                methods/operations with each context knowing how to do this, e.g.
                ServiceControllerContext -> MBeanServer
                KernelControllerContext -> Configurator (or in future as I said above BeanInfo)

                This later approach essentially moves the implementation of the Bus from
                a joinpoint based abstraction to a context based abstract.

                The main downside is that the Bus can in principle invoke on things
                that are registered directly (or indirectly via a KernelRegistryPlugin)
                that don't have a context in the controller per-se, but there is already
                "a hack" in the controller that knows how to make it seem these
                have a context.

                P.S. It is better to create JIRA issues when we have discussed the issue
                and agreed what we want to do.
                Forums == dicussions
                JIRA == what we decided needs doing

                • 5. Re: bean/mbean integration issue

                  The issue you mentioned above is a holder issue for these type of issues.
                  i.e. in this case the missing feature is being able to "install" MBeans into POJOs
                  and vice-versa.

                  • 6. Re: bean/mbean integration issue
                    alesj

                     


                    The main downside is that the Bus can in principle invoke on things
                    that are registered directly (or indirectly via a KernelRegistryPlugin)
                    that don't have a context in the controller per-se, but there is already
                    "a hack" in the controller that knows how to make it seem these
                    have a context.

                    What's the 'hack'?


                    Forums == dicussions
                    JIRA == what we decided needs doing

                    ;-)

                    "adrian@jboss.org" wrote:
                    The issue you mentioned above is a holder issue for these type of issues.
                    i.e. in this case the missing feature is being able to "install" MBeans into POJOs
                    and vice-versa.


                    Yes.
                    I'll just change the issue Summary then.

                    • 7. Re: bean/mbean integration issue
                      alesj

                      I added DispatchContext interface.

                      public interface DispatchContext
                      {
                       /**
                       * Getter property / attribute
                       *
                       * @param name
                       * @return
                       * @throws Throwable
                       */
                       Object get(String name) throws Throwable;
                      
                       /**
                       * Setter property / attribute
                       *
                       * @param property
                       * @throws Throwable
                       */
                       void set(PropertyMetaData property) throws Throwable;
                      
                       /**
                       * Invoke method / opration
                       *
                       * @param name
                       * @param parameters
                       * @return
                       * @throws Throwable
                       */
                       Object invoke(String name, List<ParameterMetaData> parameters) throws Throwable;
                      }
                      


                      This solves the issue above - should ServiceControllerContext implement it (on top of MBeanServer).

                      I'll go further with this abstraction.

                      When are we going to update the MC libs for JBoss5?
                      So that I update the Service --> MC part, with this and all other issues that I might resolve.

                      • 8. Re: bean/mbean integration issue
                        starksm64

                         

                        "alesj" wrote:

                        When are we going to update the MC libs for JBoss5?
                        So that I update the Service --> MC part, with this and all other issues that I might resolve.

                        trunk is back to pulling in the mc snapshot so any working build of the mc could be pushed out as snapshot update. I'll probably do one tonight to synch up to the snapshot I'm testing the profile service with.


                        • 9. Re: bean/mbean integration issue

                           

                          "alesj" wrote:

                          What's the 'hack'?


                          If the controller doesn't find the context, it asks the registry if it knows the name.

                          Overridden method in the kernel controller:
                           public ControllerContext getContext(Object name, ControllerState state)
                           {
                           ControllerContext context = super.getContext(name, state);
                           if (context != null)
                           return context;
                           if (state == null || state == ControllerState.INSTALLED)
                           {
                           KernelRegistry registry = kernel.getRegistry();
                           try
                           {
                           return registry.getEntry(name);
                           }
                           catch (Throwable ignored)
                           {
                           }
                           }
                           return null;
                           }
                          


                          • 10. Re: bean/mbean integration issue

                             

                            "alesj" wrote:
                            I added DispatchContext interface.


                            This interface is not correct.
                            PropertyMetaData and ParameterMetaData are POJO specific.

                            This interface belongs in the dependency module that knows nothing about
                            POJOs/services.

                            You need something like the DynamicMBean interface
                            Object get(String name) throws Throwable;
                            void set(String name, Object value) throws Throwable;
                            Object invoke(String name, String[] signature, Object[] parameters) throws Throwable;
                            


                            The kernel/pojo context will turn this into joinpoint invocations on the context's target.
                            public Object get(String name) throws Throwable
                            {
                             KernelController controller = (KernelController) getController();
                             Kernel kernel = controller.getKernel();
                             KernelConfigurator configurator = kernel.getConfigurator();
                            
                             Object object = getTarget();
                             BeanInfo info = getBeanInfo();
                            
                             TargetttedJoinpoint joinpoint = configurator.getPropertyGetterJoinpoint(info, name);
                             joinpoint.setTarget(object);
                             return joinpoint.dispatch();
                            }
                            


                            The service context will turn them into mbean invocations, e.g.
                            public Object get(String name) throws Throwable
                            {
                             return serviceController.getMBeanServer().getAttribute(objectName, name);
                            }
                            


                            • 11. Re: bean/mbean integration issue

                              If as I suggested before, the BeanInfo becomes the main entry point for these
                              operations the code would look something like:

                              public Object get(String name) throws Throwable
                              {
                               Object object = getTarget();
                               BeanInfo info = getBeanInfo();
                               return info.getPropertyValue(name, object);
                              }
                              


                              • 12. Re: bean/mbean integration issue
                                alesj

                                 

                                "adrian@jboss.org" wrote:

                                This interface is not correct.
                                PropertyMetaData and ParameterMetaData are POJO specific.

                                This interface belongs in the dependency module that knows nothing about
                                POJOs/services.

                                You need something like the DynamicMBean interface
                                Object get(String name) throws Throwable;
                                void set(String name, Object value) throws Throwable;
                                Object invoke(String name, String[] signature, Object[] parameters) throws Throwable;
                                



                                Yes.
                                I tried with this sort of impl.
                                But I saw that in order to get the actual parameter values and their (String) types I needed a lot of target info - beanInfo, methodInfo, classloader, ... Which would bloat the interface.
                                Is the target (Service, ...) always availabe to me for this sort of info?

                                • 13. Re: bean/mbean integration issue
                                  alesj

                                   

                                  "adrian@jboss.org" wrote:
                                  This interface belongs in the dependency module that knows nothing about POJOs/services.


                                  Where in the Context hierarchy should I put it?

                                  Should KernelRegistryEntry extend it?
                                  If so, how do we handle KernelRegistryPlugin entries?

                                  • 14. Re: bean/mbean integration issue
                                    alesj

                                     

                                    "scott.stark@jboss.org" wrote:

                                    trunk is back to pulling in the mc snapshot so any working build of the mc could be pushed out as snapshot update.


                                    How do you do that?
                                    Is there an Ant task in MC which does this?

                                    Since I've re-written DispatchContext to plain Object notion and put it in dependency. So once I update MC snapshot, I can add DC logic to ServiceControllerContext.

                                    1 2 Previous Next