13 Replies Latest reply: Sep 23, 2009 5:24 AM by Kabir Khan RSS

    kernel unit test failures

    Scott Marlow Master

      Is anyone else seeing this unit test failure on kernel/trunk?

      Failed tests:
       testLazy(org.jboss.test.kernel.lazy.test.JDKLazyInstantiationTestCase)
       testOnDemand(org.jboss.test.kernel.lazy.test.JDKLazyInstantiationTestCase)
       testLazy(org.jboss.test.kernel.lazy.test.JavassistLazyInstantiationTestCase)
       testOnDemand(org.jboss.test.kernel.lazy.test.JavassistLazyInstantiationTestCase)
      
      Tests in error:
       testLazyXMLTest(org.jboss.test.kernel.lazy.test.LazyMetaDataTestCase)
      
      


        • 1. Re: kernel unit test failures
          Scott Marlow Master

          More details from TEST-org.jboss.test.kernel.lazy.test.LazyMetaDataTestCase.xml are here http://pastebin.com/f30843fcf

          • 2. Re: kernel unit test failures
            Ales Justin Master

            Yeah, I get this too.
            Let me have a look at.

            • 3. Re: kernel unit test failures
              Ales Justin Master

              It's this
              KernelScopeInfo:: updateConstructorAnnotations(repository, (ComponentMutableMetaData) mutable, kernelContext, add);
              that is the culprit.

              I've added this code to escape illegal checks against external factory:

               // TODO - Kabir check if this is OK?
               // we don't handle external factories
               if (constructorMetaData.getFactory() != null || constructorMetaData.getFactoryClass() != null)
               return;
              


              Although now I get this failures:
               testInjectMcBeanIntoField(org.jboss.test.kernel.webbeans.mctowb.test.InjectMcBeansInWebBeansTestCase)
               testInjectMcBeanIntoConstructor(org.jboss.test.kernel.webbeans.mctowb.test.InjectMcBeansInWebBeansTestCase)
               testInjectMcMethodProducedBeanIntoField(org.jboss.test.kernel.webbeans.mctowb.test.InjectMcBeansInWebBeansTestCase)
               testSimple(org.jboss.test.kernel.webbeans.beanwrapper.test.BeanImplementationTestCase)
               testDecoratedType(org.jboss.test.kernel.webbeans.beanwrapper.test.BeanImplementationTestCase)

              Which I need to check if they are related.

              • 4. Re: kernel unit test failures
                Scott Marlow Master

                I'm not sure if this is related but I tried skipping the test ( mvn -Dmaven.test.skip=true install) and get:


                [INFO] ------------------------------------------------------------------------
                [ERROR] BUILD ERROR
                [INFO] ------------------------------------------------------------------------
                [INFO] Failed to resolve artifact.

                Missing:
                ----------
                1) org.jboss.kernel:jboss-kernel:test-jar:tests:2.2.0-SNAPSHOT

                Try downloading the file manually from the project website.

                Then, install it using the command:
                mvn install:install-file -DgroupId=org.jboss.kernel -DartifactId=jboss-kernel -Dversion=2.2.0-SNAPSHOT -Dclassifier=tests -Dpackaging=test-jar -Dfile=/path/to/file

                Alternatively, if you host your own repository you can deploy the file there:
                mvn deploy:deploy-file -DgroupId=org.jboss.kernel -DartifactId=jboss-kernel -Dversion=2.2.0-SNAPSHOT -Dclassifier=tests -Dpackaging=test-jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

                Path to dependency:
                1) org.jboss.kernel:jboss-aop-mc-int:jar:2.2.0-SNAPSHOT
                2) org.jboss.kernel:jboss-kernel:test-jar:tests:2.2.0-SNAPSHOT

                ----------
                1 required artifact is missing.

                for artifact:
                org.jboss.kernel:jboss-aop-mc-int:jar:2.2.0-SNAPSHOT

                from the specified remote repositories:
                central (http://repo1.maven.org/maven2),
                repository.jboss.org (http://repository.jboss.org/maven2),
                snapshots.jboss.org (http://snapshots.jboss.org/maven2)


                • 5. Re: kernel unit test failures
                  Scott Marlow Master

                  Also, I get this different (from you) after updating kernel source:

                  Results :

                  Tests in error:
                  testSetWithWildcard(org.jboss.test.kernel.deployment.xml.test.SetJaxbTestCase)

                  Tests run: 1524, Failures: 0, Errors: 1, Skipped: 0


                  • 6. Re: kernel unit test failures
                    Kabir Khan Master

                     

                    "alesj" wrote:
                    It's this
                    KernelScopeInfo:: updateConstructorAnnotations(repository, (ComponentMutableMetaData) mutable, kernelContext, add);
                    that is the culprit.

                    I've added this code to escape illegal checks against external factory:
                     // TODO - Kabir check if this is OK?
                     // we don't handle external factories
                     if (constructorMetaData.getFactory() != null || constructorMetaData.getFactoryClass() != null)
                     return;
                    


                    I might want to allow wb injection into factory method parameters later, but for now this looks ok.
                    "alesj" wrote:

                    Although now I get this failures:

                    They're not related to your fix. When getting this up and running I was relying on WB implementation details, WB has since been refactored so these are due to NoClassDefErrors. I'm working on a stable spi in WB itself to replace this. For now, I've disabled the webbeans-int tests.

                    • 7. Re: kernel unit test failures
                      Scott Marlow Master

                      I am still getting unit test failures on MC kernel trunk.

                      There are two efforts that I want to help with/work on but this unit test failure could impact them. I am interested in feedback on whether this is likely to be causing problems for me.

                      1. I couldn't integrate the jboss-mdr trunk to mc kernel trunk. I'm not sure how to resolve the classdefnotfound errors that I got only when trying to bring in the newer jboss commons jar. I updated as many sub projects to use JBoss Commons 2.2.14.GA as I could identify, but this error still occurred. This failure may be separate from this threads unit test failures but I would like help with getting the intregration going. Should I open a new thread for this effort and should I wait until these unit test failures are fixed?

                      2. I would like to start testing AS with the Parallel deployment support soon. I assume that I need to wait until these unit test failures are fixed as well. Should I ignore these failures and do a maven build with unit tests skipped to work around this? I will also need the AS configuration files that were previously tested with (maybe we can share via pastebin.

                      3. I have further ScopeKey improvements (changing some callers to pass in optimized scopekey for lookup) but need to get past #1 above first so I can test...

                      4. I started looking at the AE integration with Papaki but I will post about that on a different thread. That effort is not impacted by the unit test failure, but thought I would mention it here (since I'm give status).

                      • 8. Re: kernel unit test failures
                        Scott Marlow Master

                        I am still getting the same unit test failures (even after building with an empty local maven repo and no local kernel code changes).

                        If I skip the maven tests, I get a missing artifact error on "org.jboss.kernel:jboss-kernel:test-jar:tests:2.2.0-SNAPSHOT" (see http://pastebin.com/m189a44de)

                        Perhaps, I need some changes that others have only locally (Kabir mentioned not seeing these errors)?

                        • 9. Re: kernel unit test failures
                          Kabir Khan Master

                          The only error I get is SetJaxbTestCase error, Alexey is looking into it. This shouldn't affect what you are doing, so try excluding that one test in the pom

                          • 10. Re: kernel unit test failures
                            Scott Marlow Master

                            I asked maven to ignore the results of unit tests and I get a build failure after the setJaxTestCase error. Is this logically the same as excluding the failing test?

                            I used the following command line:

                            mvn -e test -Dmaven.test.failure.ignore=true

                            Output from running (with a clean repo and new kernel source folder) is here http://pastebin.com/m69e19ecf

                            • 11. Re: kernel unit test failures
                              Kabir Khan Master

                               

                              "smarlow@redhat.com" wrote:
                              I asked maven to ignore the results of unit tests and I get a build failure after the setJaxTestCase error. Is this logically the same as excluding the failing test?

                              I used the following command line:

                              mvn -e test -Dmaven.test.failure.ignore=true

                              I think so. I wasn't familiar with that property. So it looks like AsynchronousContextWithDependencyOnAsynchronousTestCase (the AsynchXXX tests are run via the ant plugin after the main tests) is failing for you. I've run this a few times and it passes fine for me here, so get in touch on IRC later so we can figure out why it does not work for you.



                              • 12. Re: kernel unit test failures
                                Ales Justin Master

                                Wrt the Set|Collection|...|JaxbTestCase tests, you can ignore them for now.
                                It's a XB issue:


                                The thing is the wildcard in XSD is in the choice. While in the Java
                                class it's a separate particle.

                                > > It does fail for me as well. That's a binding validation issue.
                                > >
                                > > 859 TRACE [SchemaBindingValidator] complex type
                                > > {urn:jboss:javabean:1.0}propertyType
                                > > 859 TRACE [SchemaBindingValidator] sequence
                                > > 859 TRACE [SchemaBindingValidator] expected particles:
                                > > - sequence
                                > > - sequence
                                > > actual particles:
                                > > - wildcard
                                > > 859 TRACE [SchemaBindingValidator] flattened ModelGroupBinding is missing:
                                > > 859 TRACE [SchemaBindingValidator] flattened XSModelGroup is missing:
                                > > 859 TRACE [SchemaBindingValidator] - {wildcard}wildcard

                                And I'm already discussing it with Alexey on how to fix it.

                                What you're seeing is Asynch ControllerMode tests failing.
                                I sometimes get that as well, so perhaps we're still not doing those test in proper synch deterministic manner?
                                Or it could be Byteman bug?

                                • 13. Re: kernel unit test failures
                                  Kabir Khan Master

                                   

                                  "alesj" wrote:

                                  What you're seeing is Asynch ControllerMode tests failing.
                                  I sometimes get that as well,

                                  Having run them a few times now and get occasional failures too
                                  "alesj" wrote:

                                  so perhaps we're still not doing those test in proper synch deterministic manner?
                                  Or it could be Byteman bug?

                                  Or worse, the asynch stuff isn't working as well as we thought. I'll take a look