9 Replies Latest reply on Jan 28, 2006 1:50 PM by Adrian Brock

    manual deployment of existing object instance

    Bill Burke Master

      I would like to be able to deploy an already existing object instance into the kernel and define its dependencies as well so that it can participate in lifecycle and dependency management and such. I can't find a good way to do this so far as it seems that the kernel was written only to instantiate beans and not just register them.

      Can you point me to existing test cases or example on how to do this or give pointers on how I could? I have been unable to find anything so far.

        • 1. Re: manual deployment of existing object instance
          Adrian Brock Master

          It depends (sic!) what you are trying to achieve.

          If you are just trying to add a global singleton then you can just use the
          old-fashioned static factory pattern.
          I plan to use as an example in the next release.

          i.e. How to use JBossMC to implement the "locator pattern" without using any JBossMC
          classes, including the horrible "getBean()".

          Or maybe someother factory pattern will work for you?

          If you are looking for something like the ServiceController's

          create(ObjectName, Collection dependencies)
          


          There is no current mapping (direct support) in the controller api.

          The plan is you would do it something like this:

           KernelControllerContext context = new AbstractKernelControllerContext(null, metaData, TARGET_OBJECT_HERE);
           kernelController.install(context);
          


          But currently the "InstantiateAction" will overwrite the "target".

          • 2. Re: manual deployment of existing object instance
            Bill Burke Master

            I'm currently attempting this. I'm writing an EJB3 deployer for the embedded stuff. The deployer creates EJB containers and the containers also create one or two objects that need registering for lifecycle. Of course it is an iteration until the deployer architure is ready, but here it is:

            I'll see if I can figure out something around your suggestion.

            public class MCKernelAbstraction implements KernelAbstraction
            {
             private static final Logger log = Logger.getLogger(MCKernelAbstraction.class);
            
             public static class AlreadyInstantiated extends AbstractConstructorMetaData
             {
             private Object bean;
            
             public Object create()
             {
             return bean;
             }
            
             public AlreadyInstantiated(Object bean)
             {
             this.bean = bean;
             this.setFactory(new AbstractValueMetaData(this));
             this.setFactoryClass(AlreadyInstantiated.class.getName());
             this.setFactoryMethod("create");
             }
             }
            
             private Kernel kernel;
             private MBeanServer server;
            
             public MCKernelAbstraction(Kernel kernel, MBeanServer server)
             {
             this.kernel = kernel;
             this.server = server;
             }
            
             public void install(String name, DependencyPolicy dependencies, Object service)
             {
             AbstractBeanMetaData bean = new AbstractBeanMetaData(name, service.getClass().getName());
             bean.setConstructor(new AlreadyInstantiated(service));
             MCDependencyPolicy policy = (MCDependencyPolicy) dependencies;
             bean.setDemands(policy.getDependencies());
             try
             {
             kernel.getController().install(bean);
             }
             catch (Throwable throwable)
             {
             throw new RuntimeException(throwable);
             }
             }
            


            • 3. Re: manual deployment of existing object instance
              Adrian Brock Master

              Your solution should work as just well?
              You just have the extra factory class to workaround the fact that you can't
              currently pass the target object directly.

              • 4. Re: manual deployment of existing object instance
                Adrian Brock Master

                Another solution would be to "open up" the constructors such you can pass
                an alternate KernelControllerContextActions.

                i.e. one without an "InstantiateAction".

                This is really want I plan to do when I write the ServiceControllerContextActions
                behind the different ServiceController population methods.

                • 5. Re: manual deployment of existing object instance
                  Adrian Brock Master

                   

                  "adrian@jboss.org" wrote:
                  Another solution would be to "open up" the constructors


                  Of the AbstractKernelControllerContext

                  • 6. Re: manual deployment of existing object instance
                    Adrian Brock Master

                    While we are on the subject, can you stop doing this:

                    mbeanServer = (MBeanServer)kernel.getRegistry().getEntry("MBeanServer").getTarget();
                    


                    I've already fixed a number of places where you added this and told people to do this:
                    http://www.jboss.com/index.html?module=bb&op=viewtopic&t=71739

                    It is not clear to me that this hangover from the initial port of JMX features is staying
                    in its current format.
                    http://www.jboss.com/index.html?module=bb&op=viewtopic&t=72926
                    And the registery certainly doesn't understand the cross context dependency model,
                    i.e. is it POJO or JMX

                    The correct API if you must use the kernel as a locator is:
                    kernel.getController().getInstalledContext(name).getTarget()
                    

                    Or if you are not sure it is installed
                    kernel.getController().getContext(name, null).getTarget()
                    

                    where the "null" can also be the state you expect the context to be in.

                    • 7. Re: manual deployment of existing object instance
                      Bill Burke Master

                       

                      "adrian@jboss.org" wrote:
                      Another solution would be to "open up" the constructors such you can pass
                      an alternate KernelControllerContextActions.

                      i.e. one without an "InstantiateAction".

                      This is really want I plan to do when I write the ServiceControllerContextActions
                      behind the different ServiceController population methods.


                      IMO, you are going overboard in supporting and writing all the old APIs like service controller and our JMX implementation on top of the new kernel just to be backward compatible with the < 1% of users that use this stuff. IMO, services should be migrated and refactored and rewritten to the new model and users should be forced to use the new SPIs. In a perfect world, we could be backward compatable, but there's just too much work to do.

                      • 8. Re: manual deployment of existing object instance
                        Adrian Brock Master

                         

                        "bill.burke@jboss.com" wrote:

                        IMO, you are going overboard in supporting and writing all the old APIs like service controller and our JMX implementation on top of the new kernel just to be backward compatible with the < 1% of users that use this stuff. IMO, services should be migrated and refactored and rewritten to the new model and users should be forced to use the new SPIs. In a perfect world, we could be backward compatable, but there's just too much work to do.


                        ???

                        I'm not going to rewrite everything that uses a JBoss MBean or -service.xml/sar. :-)
                        In particular, I don't see the point in POJOifying the EJB2.x container.

                        There are certainly more than 1% of users that have their own Service MBean.

                        The cross model dependency is essential for the JMX and POJO kernel models
                        to live together during the transitional period.

                        A sideaffect is that the old JMX model gains some of the new features of the POJO MC.