14 Replies Latest reply on Apr 10, 2008 9:27 AM by starksm64

    Indirect dependency names

    starksm64

      One issue I have with creating the component factory notion pattern is that the factory wants to describe relationships between components with logical names that have to be transformed into unique names for the mc beans that are installed when the factory is asked to create the component beans.

      For example, and ejb component factory would have BeanMetaData for the interceptors that included an

      AbstractInstallMetaData install = new AbstractInstallMetaData()
      install.setBean("BeanContext");
      install.setMethodName("addInterceptor");
      ...
      


      The "BeanContext" name is the logical component name portion of the bean context. When its created as an mc bean instance by the component factory, this gets transformed into a unique name using an input base name and component id number. I'm going to have to extend all of the dependency related metadata and builders to override the depends name to allow for a transformed name.

      I'm wondering if we should have consistent support for a dependency name abstraction that would allow for name transformation more easily. The existing String/Object based name methods would just call the generalized version taking a DependencyName with an IdentityDependencyName implementation:

      interface DependencyName
      {
       Object getName();
      }
      class IdentityDependencyName implements DependencyName
      {
       private Object name;
       IdentityDependencyName(Object name)...
       Object getName() { return name; }
      }
      
      class AbstractInstallMetaData
      {
       private DependencyName bean;
      
       public setBean(String bean)
       {
       setBean(new IdentityDependencyName(bean));
       }
       public setBean(DependencyName bean)
       {
       }
      }
      



        • 1. Re: Indirect dependency names

          There's an outstanding task to do the opposite.

          i.e. internally the MC will use GUIDs to identify contexts with the
          setName() just being processed as an alias. You can add aliases dynamically
          (which is I think what you are trying to achieve with the name/id?).

          If you're generating the BeanMetaData programmatically,
          there's no reason why couldn't do this yourself even before this change.

          i.e.initially do
          setName(new GUID().toString())
          then later add the alias (your IdentityDependencyName)
          to the context when you know what it is.

          • 2. Re: Indirect dependency names
            starksm64

            Ok, that should work. I'll give it a try.

            • 3. Re: Indirect dependency names
              starksm64

              Actually that still does not work. The problem is that the name has to change everytime the factory creates a new instance. Unlike the GenericBeanFactory, the notion of the ComponenentFactory is that each instance created is an mcbean. So I need a GUID()+"."+compCount type of update to the name everytime createBeans() is called.

              • 4. Re: Indirect dependency names

                I need to see something a bit more concrete to understand how this wired together.

                The idea of the GenericBeanFactory is that the GBF is controlled by the MC,
                which then creates beans that get injected from the MC components but
                those beans aren't themselves managed by the MC
                (that is unless you the GBF as a constructor factory for some other MC managed bean).

                You're saying that your factory is actually creating MC contexts during createBeans().

                Two questions:

                1) Why can't the thing that creates the MC contexts do your logical name + next number
                processing? i.e. you store next number within the factory.

                2) What unregisters the MC contexts when they are no longer required?
                i.e. what keeps track of this generated name to remove it?

                • 5. Re: Indirect dependency names
                  alesj

                  As I understand what Scott is trying to do is to have a pre-defined metadata, e.g. InstallMetaData that does 'mybean::addInterceptor'.
                  Where mybean would be determined in createBean method, mostly preprending 'baseName' and appending some number to existing meaningful name (e.g. BeanContext).

                  Reusing pre-defined metadata should be done by cloning, since when metadata moves through states, we set some member variables. Knowing where this is done is impl detail on which you should not rely - e.g. we might change the actual metadata impl.

                  Perhaps having a more open BeanMetaDataBuilder is the way to go - meaning you can provide what the actual metadata impls are we gonna use, e.g. when we do a LifecycleMetaData instantiation, one could override that with it's own impl, not using our default AbstractLifecycleMetaData.

                  • 6. Re: Indirect dependency names
                    starksm64

                     

                    "adrian@jboss.org" wrote:

                    1) Why can't the thing that creates the MC contexts do your logical name + next number
                    processing? i.e. you store next number within the factory.

                    It can, and currently does. Its just needing to rebuild the bean metadata list for the components for each new instance even though all that changes are the underlying mc bean names. In terms of types of metadata and relationships between then, nothing changes once the factory is initialized. If there was a name indirection on the dependency values then only that piece would need to be updated.

                    Actually, back to the guid idea notion, if there was auto generated id notion with a scoped alias notion such that the dependencies names used the alias scoped to the list of beans used by the factory, and the bean guid was generated each time then that is something that would work.

                    "adrian@jboss.org" wrote:

                    2) What unregisters the MC contexts when they are no longer required?
                    i.e. what keeps track of this generated name to remove it?

                    I updated the "GenericBeanFactory and install methods" thread:
                    http://www.jboss.com/index.html?module=bb&op=viewtopic&t=133332
                    with the current ComponentFactory spi, it has a destroyBeans call to unregister the beans created during createBeans.

                    This code is checked in the jboss-kernel project tests under org.jboss.test.kernel.deployment.support.container.{spi,plugin}.


                    • 7. Re: Indirect dependency names

                       

                      "alesj" wrote:

                      Perhaps having a more open BeanMetaDataBuilder is the way to go - meaning you can provide what the actual metadata impls are we gonna use,


                      You mean something like Builder::addInstallCallback(InstallCallback ic);
                      Where ic can be your own implementation. Ok.

                      But I don't think that is the issue here is it?

                      For this case (as I understand it),
                      the thing that is building the BeanMetaData just needs to do:
                      builder.addInstallCallback(method, someGeneratedName);

                      The part I don't understand is why it has to get more complicated?
                      Why do we need lots of new interfaces or methods when the thing creating
                      the BeanMetaData is the one that knows what the generated names are?

                      Like I said above, if you don't know what the generated name is
                      how are you going to uninstall it when it is no longer required?


                      • 8. Re: Indirect dependency names

                         

                        "scott.stark@jboss.org" wrote:

                        It can, and currently does. Its just needing to rebuild the bean metadata list for the components for each new instance even though all that changes are the underlying mc bean names. In terms of types of metadata and relationships between then, nothing changes once the factory is initialized. If there was a name indirection on the dependency values then only that piece would need to be updated.


                        You can't install the BeanMetaData twice (i.e. use it as template)
                        until Ales has finished the clone() stuff.

                        "adrian@jboss.org" wrote:

                        This code is checked in the jboss-kernel project tests under org.jboss.test.kernel.deployment.support.container.{spi,plugin}.


                        Ok, I'll look at it once I've finished what I'm currently working on.
                        Does it have a test that shows what it is supposed to do but doesn't currently?

                        • 9. Re: Indirect dependency names
                          starksm64

                           

                          "adrian@jboss.org" wrote:

                          Ok, I'll look at it once I've finished what I'm currently working on.
                          Does it have a test that shows what it is supposed to do but doesn't currently?

                          Yes, org.jboss.test.kernel.deployment.test.BeanContainerUsageMDTestCase.testComponentBeanFactory which calls the org.jboss.test.kernel.deployment.test.BeanContainerUsageMDTestCase.getDeploymentForComponentBeanFactory to build the programatic deployment is what is testing this. I'm updating it for the current changes to get the names correct. Right not its building the BeanMetaData list a new for each create call so I don't think the clone issue applies yet.


                          • 10. Re: Indirect dependency names
                            alesj

                            Perhaps we can create a new child Controller for every ComponentFactory?
                            Meaning we could have beans with the 'same' name living side by side, e.g. multiple BeanContext beans.

                            Annotating initial ComponentFactory instance with @ScopeFactoryLookup, and then applying the same annotation for all created beans.
                            PreInstallAction is gonna handle them, and create child Controllers accordingly.

                            I'll fix the caching of ScopeFactory in PreInstallAction.

                            • 11. Re: Indirect dependency names

                              Scott, if you commit a test that is failing can you also update the config
                              to ignore failing tests otherwise other people's builds are broken.

                              e..g

                              --- kernel/pom.xml (revision 71907)
                              +++ kernel/pom.xml (working copy)
                               <plugin>
                               <groupId>org.apache.maven.plugins</groupId>
                               <artifactId>maven-surefire-plugin</artifactId>
                              + <configuration>
                              + <testFailureIgnore>true</testFailureIgnore>
                              + </configuration>
                               </plugin>
                              


                              • 12. Re: Indirect dependency names
                                starksm64

                                Ok, will do. The tests are passing again as of now.

                                • 13. Re: Indirect dependency names

                                  So is this something I still need to look at or you've done a workaround?

                                  • 14. Re: Indirect dependency names
                                    starksm64

                                    I have a workaround, and Ales has another approach as well so I'm good for now.