14 Replies Latest reply on Nov 4, 2008 11:44 PM by starksm64

    JBMICROCONT-243 - parsing and managed objects

      http://jira.jboss.com/jira/browse/JBMICROCONT-243

      I don't understand this JIRA issue?

      It's true that the parser may not run if the metadata is passed in programmatically,
      but that doesn't effect the ManagedObjectCreator call.

      The parser deployer doesn't care where the metadata came from,
      it just looks for the attachment and asks the ManagedObjectFactory to create
      the ManagedObject from it.

        • 1. Re: JBMICROCONT-243 - parsing and managed objects
          starksm64

          Right, but I can see configurations that don't even include parsing deployers. I'm thinking I want the default ManagedObjectCreator impl to be a separate deployer where overrides for the ManagedObjectCreator for a given attachment type can be configured.

          • 2. Re: JBMICROCONT-243 - parsing and managed objects
            starksm64

            This is now JBDEPLOY-79. Another issue with the current AbstractParsingDeployerWithOutput implementation of ManagedObjectCreator is that its using the ManagedObjectFactoryBuilder.create() to obtain the ManagedObjectFactory. This is only coincidentally mapping to the ManagedObjectFactory bean now being created in the bootstrap deployers.xml, against which the BeanMetaDataICF and ServiceMetaDataICF beans register:

             <!-- The ManagedObjectFactory -->
             <bean name="ManagedObjectFactory">
             <constructor factoryClass="org.jboss.managed.api.factory.ManagedObjectFactory" factoryMethod="getInstance"/>
             </bean>
            ...
             <!-- POJO Deployment -->
             <bean name="BeanMetaDataICF" class="org.jboss.deployers.plugins.managed.BeanMetaDataICF">
             <install bean="ManagedObjectFactory" method="setInstanceClassFactory">
             <parameter>
             <value>org.jboss.beans.metadata.spi.BeanMetaData</value>
             </parameter>
             <parameter>
             <this />
             </parameter>
             </install>
             <uninstall bean="ManagedObjectFactory" method="setInstanceClassFactory">
             <parameter>
             <value>org.jboss.beans.metadata.spi.BeanMetaData</value>
             </parameter>
             <parameter>
             <null />
             </parameter>
             </uninstall>
             <property name="controller"><inject bean="jboss.kernel:service=KernelController"/></property>
             </bean>
            ...
             <!-- JMX Deployment -->
             <bean name="ServiceMetaDataICF" class="org.jboss.system.deployers.managed.ServiceMetaDataICF">
             <property name="mbeanServer"><inject bean="JMXKernel" property="mbeanServer"/></property>
             <install bean="ManagedObjectFactory" method="setInstanceClassFactory">
             <parameter>
             <value>org.jboss.system.metadata.ServiceMetaData</value>
             </parameter>
             <parameter>
             <this />
             </parameter>
             </install>
             <uninstall bean="ManagedObjectFactory" method="setInstanceClassFactory">
             <parameter>
             <value>org.jboss.system.metadata.ServiceMetaData</value>
             </parameter>
             <parameter>
             <null />
             </parameter>
             </uninstall>
             </bean>
            


            I would like to break the ManagedObjectCreator into a separate DeploymentStage.INSTALLED deployer that has the ManagedObjectFactory injected into it.

            Any objections?

            Is this the last change to cut the JBDEPLOY-2.0.0.GA, or is a JBDEPLOY-2.0.0.CR4 needed?


            • 3. Re: JBMICROCONT-243 - parsing and managed objects
              alesj

               

              "scott.stark@jboss.org" wrote:

               <!-- The ManagedObjectFactory -->
               <bean name="ManagedObjectFactory">
               <constructor factoryClass="org.jboss.managed.api.factory.ManagedObjectFactory" factoryMethod="getInstance"/>
               </bean>
              ...
               <!-- POJO Deployment -->
               <bean name="BeanMetaDataICF" class="org.jboss.deployers.plugins.managed.BeanMetaDataICF">
               <install bean="ManagedObjectFactory" method="setInstanceClassFactory">
               <parameter>
               <value>org.jboss.beans.metadata.spi.BeanMetaData</value>
               </parameter>
               <parameter>
               <this />
               </parameter>
               </install>
               <uninstall bean="ManagedObjectFactory" method="setInstanceClassFactory">
               <parameter>
               <value>org.jboss.beans.metadata.spi.BeanMetaData</value>
               </parameter>
               <parameter>
               <null />
               </parameter>
               </uninstall>
               <property name="controller"><inject bean="jboss.kernel:service=KernelController"/></property>
               </bean>
              ...
               <!-- JMX Deployment -->
               <bean name="ServiceMetaDataICF" class="org.jboss.system.deployers.managed.ServiceMetaDataICF">
               <property name="mbeanServer"><inject bean="JMXKernel" property="mbeanServer"/></property>
               <install bean="ManagedObjectFactory" method="setInstanceClassFactory">
               <parameter>
               <value>org.jboss.system.metadata.ServiceMetaData</value>
               </parameter>
               <parameter>
               <this />
               </parameter>
               </install>
               <uninstall bean="ManagedObjectFactory" method="setInstanceClassFactory">
               <parameter>
               <value>org.jboss.system.metadata.ServiceMetaData</value>
               </parameter>
               <parameter>
               <null />
               </parameter>
               </uninstall>
               </bean>
              


              You could perhaps change that type to which ICF is mapped against
              is contract of ICF:
              public interface ICF<T>
              {
               Class<T> getType();
              }
              

              then you could use callback mechanism on ManagedObjectFactory,
              reducing this installs xml. ;-)

              "scott.stark@jboss.org" wrote:

              I would like to break the ManagedObjectCreator into a separate DeploymentStage.INSTALLED deployer that has the ManagedObjectFactory injected into it.

              Any objections?

              Meaning you would remove current man+deployers code
              and create new deployer - at INSTALLED stage?

              "scott.stark@jboss.org" wrote:

              Is this the last change to cut the JBDEPLOY-2.0.0.GA, or is a JBDEPLOY-2.0.0.CR4 needed?

              I'll probably cut new MC and Deployers release.
              To at least test current changes for a few days in AS.
              Let me know when you're done with your changes.

              • 4. Re: JBMICROCONT-243 - parsing and managed objects
                starksm64

                 

                "alesj" wrote:

                You could perhaps change that type to which ICF is mapped against
                is contract of ICF:
                public interface ICF<T>
                {
                 Class<T> getType();
                }
                

                then you could use callback mechanism on ManagedObjectFactory,
                reducing this installs xml. ;-)

                I'll do that when I add the MetaData api change.

                "alesj" wrote:

                Meaning you would remove current man+deployers code
                and create new deployer - at INSTALLED stage?

                Its just the current ManagedObjectCreator implementation in AbstractParsingDeployerWithOutput that would be moved into a new deployer that would be added to deployers.xml and runs at the INSTALLED stage.

                "alesj" wrote:

                I'll probably cut new MC and Deployers release.
                To at least test current changes for a few days in AS.
                Let me know when you're done with your changes.

                Ok. I need a jboss-managed 2.0.0.CR4 to be able to pass the deployment unit MetaData in the new ManagedObjectCreatorDeployer. I'll test in first in the jbossas codebase.


                • 5. Re: JBMICROCONT-243 - parsing and managed objects
                  starksm64

                  Actually, it should not be a deployer as it would be a deployer with no known inputs/outputs on which to generate the managed object for. There just should be a ManagedObjectCreator implementation that has the ManagedObjectFactory injected, and this in turn is injected into the DeployerWrapper/DeployersImpl. Right now the DeployerWrapper initializes its the ManagedObjectCreator from the Deployer if it implements that. This logic could be kept so that deployers could provide an override, but typically they would customize behavior using an InstanceClassFactory registration.

                  • 6. Re: JBMICROCONT-243 - parsing and managed objects
                    starksm64

                     

                    "alesj" wrote:

                    You could perhaps change that type to which ICF is mapped against
                    is contract of ICF:
                    public interface ICF<T>
                    {
                     Class<T> getType();
                    }
                    



                    Where is this getType used to build the callback signature?

                    • 7. Re: JBMICROCONT-243 - parsing and managed objects
                      alesj

                       

                      "scott.stark@jboss.org" wrote:

                      Where is this getType used to build the callback signature?

                      Nowhere. ;-)
                      You're gonna use it.
                      e.g.
                      public class ICFHolder
                      {
                       private Map<Class, ICF> ifcs = new HashMap();
                      
                       public void addICF(ICF icf)
                       {
                       icfs.put(icf.getType(), icf);
                       }
                      
                       ...
                      }
                      

                      Where callback would be on the addICF/removeICF.
                      getType is only there if you want to keep your map,
                      to know by the ICF::type which ICF to use on attachment.

                      • 8. Re: JBMICROCONT-243 - parsing and managed objects
                        starksm64

                        Thank goodness, I had spent an hour trying figure out how in the hell it was being used !

                        • 9. Re: JBMICROCONT-243 - parsing and managed objects
                          starksm64

                          this has been committed to trunk and the 2.0 branch. I had tested the 2.2.0-SNAPSHOT, but currently I'm unable to validate the 2.0 branch because even after adding -Djboss.vfs.cache=org.jboss.virtual.plugins.cache.WeakRefVFSCache, the profileservice config seems to be in a spin loop. I'm trying to see where, but will probably wait for the VFS 2.0.0.CR3 change.

                          • 10. Re: JBMICROCONT-243 - parsing and managed objects
                            alesj

                             

                            "scott.stark@jboss.org" wrote:
                            I had tested the 2.2.0-SNAPSHOT, but currently I'm unable to validate the 2.0 branch because even after adding -Djboss.vfs.cache=org.jboss.virtual.plugins.cache.WeakRefVFSCache, the profileservice config seems to be in a spin loop. I'm trying to see where, but will probably wait for the VFS 2.0.0.CR3 change.

                            I'm done. Committed my changes to jbossas trunk.
                            But I'm still interested in this loops ...

                            • 11. Re: JBMICROCONT-243 - parsing and managed objects
                              starksm64

                              Ok, I'm looking at this on another workspace where I don't have the jboss-managed 2.0.0.CR4 and jboss-deployer 2.0.0-SNAPSHOT changes to better isolate it.

                              • 12. Re: JBMICROCONT-243 - parsing and managed objects
                                starksm64

                                Its running ok now on the workspace without the jboss-managed 2.0.0.CR4 and jboss-deployer 2.0.0-SNAPSHOT changes, so I'll recheck there.

                                • 13. Re: JBMICROCONT-243 - parsing and managed objects
                                  starksm64

                                  There profileservice config is starting, but the profileservice-tests are hanging and timing out half way through the seam tests. I'll send a couple of thread dumps I have while the server looked to be in a loop.

                                  • 14. Re: JBMICROCONT-243 - parsing and managed objects
                                    starksm64

                                    Looking at the results more closely, it just looks like the tests are running much slower. In the workspace without the deployers/managed changes. the current trunk seam test times are much slower:

                                     [junit] Running org.jboss.test.deployers.seam.test.SeamBookingExampleUnitTestCase
                                     [junit] Running org.jboss.test.deployers.seam.test.SeamBookingExampleUnitTestCase
                                     [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 156.178 sec
                                     [junit] Running org.jboss.test.deployers.seam.test.SeamDvdExampleUnitTestCase
                                     [junit] Running org.jboss.test.deployers.seam.test.SeamDvdExampleUnitTestCase
                                     [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 136.713 sec
                                     [junit] Test org.jboss.test.deployers.seam.test.SeamDvdExampleUnitTestCase FAILED
                                     [junit] Running org.jboss.test.deployers.seam.test.SeamJpaExampleUnitTestCase
                                     [junit] Running org.jboss.test.deployers.seam.test.SeamJpaExampleUnitTestCase
                                     [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 183.403 sec
                                     [junit] Running org.jboss.test.deployers.seam.test.SeamNumberguessExampleUnitTestCase
                                     [junit] Running org.jboss.test.deployers.seam.test.SeamNumberguessExampleUnitTestCase
                                     [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 79.059 sec
                                     [junit] Running org.jboss.test.deployers.seam.test.SeamVFSClassloadingUnitTestCase
                                     [junit] Running org.jboss.test.deployers.seam.test.SeamVFSClassloadingUnitTestCase
                                     [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 25.384 sec
                                    ...
                                    Total time: 14 minutes 12 seconds
                                    


                                    Than the r80362 AS trunk with jboss-vfs 2.0.0.CR1
                                     [junit] Running org.jboss.test.deployers.seam.test.SeamBookingExampleUnitTestCase
                                     [junit] Running org.jboss.test.deployers.seam.test.SeamBookingExampleUnitTestCase
                                     [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 16.669 sec
                                     [junit] Running org.jboss.test.deployers.seam.test.SeamDvdExampleUnitTestCase
                                     [junit] Running org.jboss.test.deployers.seam.test.SeamDvdExampleUnitTestCase
                                     [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 20.967 sec
                                     [junit] Running org.jboss.test.deployers.seam.test.SeamJpaExampleUnitTestCase
                                     [junit] Running org.jboss.test.deployers.seam.test.SeamJpaExampleUnitTestCase
                                     [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 9.774 sec
                                     [junit] Running org.jboss.test.deployers.seam.test.SeamNumberguessExampleUnitTestCase
                                     [junit] Running org.jboss.test.deployers.seam.test.SeamNumberguessExampleUnitTestCase
                                     [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 7.229 sec
                                     [junit] Running org.jboss.test.deployers.seam.test.SeamVFSClassloadingUnitTestCase
                                     [junit] Running org.jboss.test.deployers.seam.test.SeamVFSClassloadingUnitTestCase
                                     [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 7.133 sec
                                    ...
                                    Total time: 5 minutes 28 seconds