7 Replies Latest reply on Apr 2, 2008 11:19 AM by Kabir Khan

    NPE with new parsing in aop-mc-int tests

    Ales Justin Master

      I get a bunch of NPEs while testing aop-mc-int.
      The exception comes from

      java.lang.NullPointerException
       at org.jboss.kernel.plugins.deployment.AbstractKernelDeployment.getBeans(AbstractKernelDeployment.java:227)
       at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBeans(AbstractKernelDeployer.java:304)
       at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deploy(AbstractKernelDeployer.java:133)
       at org.jboss.kernel.plugins.deployment.BasicKernelDeployer.deploy(BasicKernelDeployer.java:76)
       at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:88)
       at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:158)
       at org.jboss.test.kernel.junit.MicrocontainerTestDelegate.deploy(MicrocontainerTestDelegate.java:294)
       at org.jboss.test.kernel.junit.MicrocontainerTest.deploy(MicrocontainerTest.java:325)
      

      which is this line
       for (BeanMetaDataFactory factory : factories)
       {
      XXX List<BeanMetaData> beans = factory.getBeans();
      


      Debuging the thing showed that normal mc beans are there as factories, it's the aop specfic stuff that is put there as a null.

      Who matches/produces this null?

        • 1. Re: NPE with new parsing in aop-mc-int tests
          Adrian Brock Master

           

          "alesj" wrote:

          Who matches/produces this null?


          It's a long standing bug in JBossXB. It basically means it didn't figure out how
          to create the object.

          But we shouldn't be throwing an NPE there. We should have something more
          informative.

          • 2. Re: NPE with new parsing in aop-mc-int tests
            Ales Justin Master

             

            "adrian@jboss.org" wrote:

            It's a long standing bug in JBossXB. It basically means it didn't figure out how
            to create the object.

            Yup.
            I've traced it down to not understanding aop:lifecycle-configure.
            Or any aop:lifecycle-(state) for that matter.

            Kabir, I thought you said the new jbossxb+aop_mc is a superset of previous schema initializers? ;-)

            "adrian@jboss.org" wrote:

            But we shouldn't be throwing an NPE there. We should have something more
            informative.

            Definitely. :-)
            But this should be already handled in JBossXB.
            Otherwise we can add all sorts of NPE checks throughout our metadata classes, if we cannot trust JBossXB to deal with them before.


            • 3. Re: NPE with new parsing in aop-mc-int tests
              Adrian Brock Master

               

              "alesj" wrote:

              "adrian@jboss.org" wrote:

              But we shouldn't be throwing an NPE there. We should have something more
              informative.

              Definitely. :-)
              But this should be already handled in JBossXB.
              Otherwise we can add all sorts of NPE checks throughout our metadata classes, if we cannot trust JBossXB to deal with them before.


              What does JBossXB have to do with the following code?
              KernelDeployment dep = new AbstractKernelDeployment("test");
              dep.setBeans(Arrays.asList((BeanMetaDataFactory) null));
              

              which produces the same error.

              • 4. Re: NPE with new parsing in aop-mc-int tests
                Ales Justin Master

                 

                "adrian@jboss.org" wrote:

                What does JBossXB have to do with the following code?
                KernelDeployment dep = new AbstractKernelDeployment("test");
                dep.setBeans(Arrays.asList((BeanMetaDataFactory) null));
                

                which produces the same error.

                Good point. :-)

                I'll fix/handle this together with this:
                "adrian@jboss.org" wrote:

                "adrian@jboss.org" wrote:

                | Then in the part where the deployment/bean are checked for classloader
                | AbstractKernelDeployer::deploybean()


                While I am on this subject.

                I originally put all the deployment defaults in this method, but other
                defaults have been added in the AbstractKernelDeployment::getBeans().

                I think the AbstractKernelDeployment is the correct place for this code,
                so we should look at moving all the logic that is AbstractKernelDeployer::deployBean()
                into there.

                Especially since the AbstractKernelDeployer is not always used,
                e.g. the BeanMetaDeployer in the deployers project.


                • 5. Re: NPE with new parsing in aop-mc-int tests
                  Kabir Khan Master

                  I haven't changed anything in that area, so most likely this is caused by the upgrade to JBoss XB? That upgrade would use the org.jboss.aop.microcontainer.beans.metadata.AOPDeployment class as the root of JAXB parsing instead of the aop bean schemainitializer. Since AOPDeployment does not exist in mc trunk, how does the aop stuff even get parsed at the moment?

                  I can switch to use the JAXB stuff later today:
                  http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4140727#4140727

                  • 6. Re: NPE with new parsing in aop-mc-int tests
                    Ales Justin Master

                     

                    "kabir.khan@jboss.com" wrote:
                    Since AOPDeployment does not exist in mc trunk, how does the aop stuff even get parsed at the moment?

                    I've got this
                    package org.jboss.aop.microcontainer.beans.beanmetadatafactory;
                    
                    import java.util.List;
                    
                    import javax.xml.bind.annotation.XmlAnyElement;
                    import javax.xml.bind.annotation.XmlElement;
                    import javax.xml.bind.annotation.XmlElements;
                    import javax.xml.bind.annotation.XmlNsForm;
                    import javax.xml.bind.annotation.XmlRootElement;
                    import javax.xml.bind.annotation.XmlType;
                    
                    import org.jboss.beans.metadata.spi.BeanMetaDataFactory;
                    import org.jboss.kernel.plugins.deployment.AbstractKernelDeployment;
                    import org.jboss.managed.api.annotation.ManagementObject;
                    import org.jboss.managed.api.annotation.ManagementProperties;
                    import org.jboss.xb.annotations.JBossXmlSchema;
                    
                    /**
                     *
                     * @author <a href="kabir.khan@jboss.com">Kabir Khan</a>
                     * @version $Revision: 1.1 $
                     */
                    @ManagementObject(properties = ManagementProperties.EXPLICIT) // TODO - explicitly add props we want to manage
                    @JBossXmlSchema(namespace="urn:jboss:aop-beans:1.0", elementFormDefault=XmlNsForm.QUALIFIED)
                    @XmlRootElement(name="aop")
                    @XmlType(propOrder={"annotations", "classLoader", "beanFactories", "create", "start", "stop", "destroy", "aliases"})
                    public class AOPDeployment extends AbstractKernelDeployment
                    {
                     private static final long serialVersionUID = 1L;
                    
                    
                     @XmlElements
                     ({
                     @XmlElement(name="aspect", type=AspectBeanMetaDataFactory.class),
                     @XmlElement(name="interceptor", type=InterceptorBeanMetaDataFactory.class),
                     @XmlElement(name="bind", type=BindBeanMetaDataFactory.class),
                     @XmlElement(name="stack", type=StackBeanMetaDataFactory.class),
                     @XmlElement(name="typedef", type=TypeDefBeanMetaDataFactory.class),
                     @XmlElement(name="cflow-stack", type=CFlowStackBeanMetaDataFactory.class)
                     })
                     @XmlAnyElement
                     public void setBeanFactories(List<BeanMetaDataFactory> beanFactories)
                     {
                     super.setBeanFactories(beanFactories);
                     }
                    }
                    

                    Looks like old stuff (see diff package):
                     addJaxbSchema("urn:jboss:aop-beans:1.0", "org.jboss.aop.microcontainer.beans.metadata.AOPDeployment");
                    

                    Why is it still there? :-)

                    If the metadata class is not there, you get this ignore in SingletonSchemaResolverFactory:
                     public boolean addJaxbSchema(String namespace, String reference)
                     {
                     try
                     {
                     resolver.addClassBinding(namespace, reference);
                     if (log.isTraceEnabled())
                     log.trace("Mapped '" + namespace + "' to '" + reference + "'");
                     return true;
                     }
                     catch (Exception ignored)
                     {
                     if (log.isTraceEnabled())
                     log.trace("Ignored: ", ignored);
                     return false;
                     }
                     }
                    


                    And then you get the null in beanfactories - a jbossxb problem Adrian mentioned.

                    • 7. Re: NPE with new parsing in aop-mc-int tests
                      Kabir Khan Master

                       

                       addJaxbSchema("urn:jboss:aop-beans:1.0", "org.jboss.aop.microcontainer.beans.metadata.AOPDeployment");
                      


                      is correct, I moved this out for the release 2 weeks ago as mentioned on another thread. The org.jboss.aop.microcontainer.beans.beanmetadatafactory stuff is old and uses the AOPBeanSchemaInitializer. The way it uses the JAXB annotations is wrong as used on another thread.

                      My question was mainly a warning that I will introduce the beans.metadata package again and switch to doing it that way.

                      What is in mc trunk will only work with JBossXB 2.0.0.CR7

                      What I want to put in will only work with JBossXB 2.0.0.CR8

                      The "old" way and the "new" way can probably live side by side for a while, but if the target version of JBossXB in AS trunk is 2.0.0.CR8 I might as well get rid of the "old" way once and for all.