5 Replies Latest reply on Oct 4, 2007 6:49 AM by Ales Justin

    New KernelBus lookup failure

    Ales Justin Master

      I'm having problems locating runtime component via new KernelBus lookup.

      The lookup goes over KernelRegistry, which eventually delegates things to registered KernelRegistryPlugins.
      Currenty there are three KernelRegistryPlugins: BasicKernelRegistryFactory, AbstractKernelController, JNDIKernelRegistryPlugin.

      OK, we can forget about the last one - JNDI.

      But the thing is that neither of the first two is able to find simple 'name=DefaultDS,service=ManagedConnectionPool' service.
      Looking at the AbstractKernelController makes it clear, since this service is not a POJO supplier. But one would expect to find it in the first registry.

      What's the idea/algorithm what goes into BasicKernelRegistryFactory and is not present as installed ControllerContext in Controller and vice versa?
      Since I get 188 entries in BasicKernelRegistryFactory and 359 Installed contexts in Controller. And BasicKernelRegistryFactory doesn't return service, where Controller.getInstalledContext returns the service context.

      I'm running AS5 profileservice configuration.

        • 1. Re: New KernelBus lookup failure
          Scott Stark Master

          Looking at the ServiceControllerContext ctor, its passing in the full mbean ObjectName using the name.getCanonicalName() form, so the full name should be:

          jboss.jca:name=DefaultDS,service=ManagedConnectionPool

          which includes the jmx domain name.

          • 2. Re: New KernelBus lookup failure
            Ales Justin Master

             

            "scott.stark@jboss.org" wrote:
            Looking at the ServiceControllerContext ctor, its passing in the full mbean ObjectName using the name.getCanonicalName() form, so the full name should be:

            jboss.jca:name=DefaultDS,service=ManagedConnectionPool

            which includes the jmx domain name.

            Sure, I would expect that from this:
            http://anonsvn.jboss.org/repos/jbossas/trunk/profileservice/src/main/org/jboss/profileservice/management/BasicMetaDataNameProvider.java

            I'll have a look again tomorrow to see where I'm missing domain name ...

            • 3. Re: New KernelBus lookup failure
              Ales Justin Master

               

              "alesj" wrote:

              simple 'name=DefaultDS,service=ManagedConnectionPool' service

              This part is wrong. And I know why. :-)
              I copied the name from jmx-console web site, which has domain name on top.
              So that's why jboss.jca is missing.

              And I also know why the difference in sizes.
              And why I'm not able to find my service.
              Going to bed early and thinking about this things always helps. :-)

              The difference is in MBeans being registered through ServiceController, which doesn't add installed MBean to KernelRegister - since ServiceControllerContext doesn't implement KernelRegistryEntry.

              Since all this code is org.jboss.kernel aware:
              ServiceController.java[(46, 8) |import| |org|.|jboss|.|kernel|.|Kernel|;, (47, 8) |import| |org|.|jboss|.|kernel|.|plugins|.|bootstrap|.|basic|.|BasicBootstrap|;, (48, 8) |import| |org|.|jboss|.|kernel|.|spi|.|dependency|.|KernelController|;]
              (46, 8) |import| |org|.|jboss|.|kernel|.|Kernel|;
              (47, 8) |import| |org|.|jboss|.|kernel|.|plugins|.|bootstrap|.|basic|.|BasicBootstrap|;
              (48, 8) |import| |org|.|jboss|.|kernel|.|spi|.|dependency|.|KernelController|;
              
              rg.jboss.system.metadata[ServiceInjectionValueMetaData.java[(32, 8) |import| |org|.|jboss|.|kernel|.|spi|.|config|.|KernelConfigurator|;, (33, 8) |import| |org|.|jboss|.|kernel|.|spi|.|dependency|.|KernelController|;],
              
              ServiceValueContext.java[(27, 8) |import| |org|.|jboss|.|kernel|.|Kernel|;, (28, 8) |import| |org|.|jboss|.|kernel|.|spi|.|dependency|.|KernelController|;]]
              
              ServiceInjectionValueMetaData.java[(32, 8) |import| |org|.|jboss|.|kernel|.|spi|.|config|.|KernelConfigurator|;, (33, 8) |import| |org|.|jboss|.|kernel|.|spi|.|dependency|.|KernelController|;]
              (32, 8) |import| |org|.|jboss|.|kernel|.|spi|.|config|.|KernelConfigurator|;
              (33, 8) |import| |org|.|jboss|.|kernel|.|spi|.|dependency|.|KernelController|;
              
              ServiceValueContext.java[(27, 8) |import| |org|.|jboss|.|kernel|.|Kernel|;, (28, 8) |import| |org|.|jboss|.|kernel|.|spi|.|dependency|.|KernelController|;]
              (27, 8) |import| |org|.|jboss|.|kernel|.|Kernel|;
              (28, 8) |import| |org|.|jboss|.|kernel|.|spi|.|dependency|.|KernelController|;
              org.jboss.system.server.jmx[JMXKernel.java[(46, 8) |import| |org|.|jboss|.|kernel|.|Kernel|;]]
              
              JMXKernel.java[(46, 8) |import| |org|.|jboss|.|kernel|.|Kernel|;]
              (46, 8) |import| |org|.|jboss|.|kernel|.|Kernel|;
              

              it's probably the easiest way to add that ServiceControllerContext implements KernelRegistryEntry, and when the MBean is installed (in InstallAction) it is added to the KernelRegistry.

              If so, what about the MBeans that are only running these actions: ServiceControllerContextActions.getLifecycleOnly() ?

              I guess since InstallAction is currently an empty impl, adding InstallAction to LifecycleOnly won't be a problem?

              • 4. Re: New KernelBus lookup failure
                Adrian Brock Master

                Why don't you just change the KernelBus to use the
                getInstalledContext()
                on the controller rather than the KernelRegistry.

                I want to deprecate the KernelRegistry in a future release, it's original purpose
                was to combine the MBeanRegistry and the POJO registry, but that hasn't been
                done and it is acutally unnecessary since I switched the design to make
                the integration at the controller rather than the registry.

                The only usecase now for the KernelRegistry is the KernelRegistryPlugin
                or direct registration (currently only the basic kernel objects do this)
                which are features that could be added to the controller anyway.

                • 5. Re: New KernelBus lookup failure
                  Ales Justin Master

                   

                  "adrian@jboss.org" wrote:
                  Why don't you just change the KernelBus to use the getInstalledContext() on the controller rather than the KernelRegistry.

                  I'm already done with the change - since it was a minor one and I didn't know KernelRegistry was going away. :-(
                  But, yes, I can simply change KernelBus to look for installed contexts. :-)

                  "adrian@jboss.org" wrote:

                  The only usecase now for the KernelRegistry is the KernelRegistryPlugin
                  or direct registration (currently only the basic kernel objects do this)
                  which are features that could be added to the controller anyway.

                  I added a BeanKernelRegistryEntry for those kernel objects in order to be able to use AttributeDispatchContext in ServiceInjectionValueMetaData (unifying the way we invoke propertys) - some Scott's code relies on invoking property on kernel objects.
                   protected KernelRegistryEntry createKernelRegistryEntry(Kernel kernel, Object object) throws Throwable
                   {
                   KernelConfig config = kernel.getConfig();
                   BeanInfo info = config.getBeanInfo(object.getClass());
                   return new BeanKernelRegistryEntry(object, info);
                   }