1 2 Previous Next 23 Replies Latest reply on Oct 5, 2007 11:14 AM by starksm64

    JBossXB-2.0.0.CR5

    starksm64

      We need a release of the combined jbossxb/jbossxb-builder that at least has JBXB-109 working in some form. As I mentioned on another thread, there are unit test issues as well that are due to both defaults overrides, and apparent regressions due to thirdparty updates.

        • 1. Re: JBossXB-2.0.0.CR5
          aloubyansky

          I wanted to mention sporadic errors I saw today. The current results are:
          tests: 638
          errors: 308
          failures: 8

          But there was a run where I got
          tests: 638
          errors: 388
          failures: 12

          The errors were related to not being able to find getter methods for properties. The reason was that instead of introspecting the class which had both getter and setter methods for a property, an interface that declared only the setter method for that property and which was implemented by the class was introspected.

          For that reason all the tests (224) in org.jboss.test.xb.builder.object.mc.test failed.
          Example of the exception message:

          Expected a getter for annotations in org.jboss.test.xb.builder.object.mc.support.model.BeanMetaData at org.jboss.test.xb.builder.object.mc.support.model.BeanMetaData.annotations at org.jboss.test.xb.builder.object.mc.support.model.AbstractBeanMetaData.beans at org.jboss.test.xb.builder.object.mc.support.model.AbstractKernelDeployment.beanFactories at org.jboss.test.xb.builder.object.mc.support.model.AbstractKernelDeployment


          W/o making any changes just rebuilding and rerunning the issue went away.

          • 2. Re: JBossXB-2.0.0.CR5
            starksm64

            It does not appear to be picking up the type from the annotation. For example, when I run the org.jboss.test.xb.builder.object.mc.test.BeanTestCase.testBeanWithAnnotation test, its failing with an attempt to create an interface instance:


            Caused by: org.jboss.joinpoint.spi.JoinpointException: Constructor not found org.jboss.test.xb.builder.object.mc.support.model.AnnotationMetaData[] no constructors
            at org.jboss.joinpoint.plugins.Config.findConstructorInfo(Config.java:276)
            at org.jboss.joinpoint.plugins.Config.getConstructorJoinpoint(Config.java:150)
            at org.jboss.beans.info.plugins.AbstractBeanInfo.newInstance(AbstractBeanInfo.java:221)
            at org.jboss.beans.info.plugins.AbstractBeanInfo.newInstance(AbstractBeanInfo.java:216)
            at org.jboss.xb.spi.AbstractBeanAdapter.construct(AbstractBeanAdapter.java:115)


            The corresponding property is annotated with the concrete type that should be used however:

             @XmlElement(name="annotation", type=AbstractAnnotationMetaData.class)
             public void setAnnotations(Set<AnnotationMetaData> annotations)
             {
             this.annotations = annotations;
             flushJBossObjectCache();
             }
            



            • 3. Re: JBossXB-2.0.0.CR5
              starksm64

              The problem is this section of code for collections. The annotation property is a collection, and there is no XmlType annotation, so this gets executed:

               // a collection may be bound as a value of a complex type
               // and this is checked with the XmlType annotation
               else if (propertyType.isCollection() && ((ClassInfo) propertyType).getUnderlyingAnnotation(XmlType.class) == null)
               {
               isCol = true;
               propertyHandler = new CollectionPropertyHandler(property, propertyType);
               ClassInfo typeArg = (ClassInfo) findComponentType(property);
              
               //if (((ClassInfo) typeArg).getUnderlyingAnnotation(XmlType.class) != null)
               if (typeArg != null && typeArg.getUnderlyingAnnotation(JBossXmlModelGroup.class) == null)
               {// it may be a model group in which case we don't want to change the type
              
               // TODO yes, this is another hack with collections
               JBossXmlChild xmlChild = ((ClassInfo) propertyType).getUnderlyingAnnotation(JBossXmlChild.class);
               if (xmlChild == null)
               {
               localPropertyType = typeArg;
               }
               }
               }
              

              This ends up overriding the localPropertyType (that has been correctly set previously from the XmlElement) to the interface class. The typeArg is a collection of the interface class when it should be a collection of the overriden localPropertyType.

              I guess the findComponentType(property) call needs to take the localPropertyType as well as the CollectionPropertyHandler ctor.


              • 4. Re: JBossXB-2.0.0.CR5
                starksm64

                Correction, typeArg is not a collection, its the collection parameter type.

                • 5. Re: JBossXB-2.0.0.CR5
                  starksm64

                  The CollectionPropertyHandler type still needs to be the propertyType as the localPropertyType is only the colllection parameter type when overriden. If the localPropertyType is only overriden when it has not already been set to something other than the propertyType:

                   else if (propertyType.isCollection() && ((ClassInfo) propertyType).getUnderlyingAnnotation(XmlType.class) == null)
                   {
                   isCol = true;
                   propertyHandler = new CollectionPropertyHandler(property, propertyType);
                   ClassInfo typeArg = (ClassInfo) findComponentType(property);
                  
                   //if (((ClassInfo) typeArg).getUnderlyingAnnotation(XmlType.class) != null)
                   if (typeArg != null && typeArg.getUnderlyingAnnotation(JBossXmlModelGroup.class) == null)
                   {// it may be a model group in which case we don't want to change the type
                  
                   // TODO yes, this is another hack with collections
                   JBossXmlChild xmlChild = ((ClassInfo) propertyType).getUnderlyingAnnotation(JBossXmlChild.class);
                   if (xmlChild == null && localPropertyType.equals(propertyType))
                   {
                   localPropertyType = typeArg;
                   }
                   }
                   }
                  

                  Then all of the BeanTestCase tests pass, and of the 224 mc tests, there are only 9 failures. All the failures are xxxWithValue() tests where the value is null rather than as expected.


                  • 6. Re: JBossXB-2.0.0.CR5
                    aloubyansky

                    After moving the override of the default xb handlers to setUp and restoring them in tearDown of AbstractBuilderTest the status is 16 errors and 20 failures.

                    • 7. Re: JBossXB-2.0.0.CR5
                      aloubyansky

                      The following collection bindings are wrong, so I am commenting them. They started to cause errors after Scott's fix.

                      Index: src/test/java/org/jboss/ejb/metadata/spec/MethodPermissionMetaData.java
                      ===================================================================
                      --- src/test/java/org/jboss/ejb/metadata/spec/MethodPermissionMetaData.java (revision 2575)
                      +++ src/test/java/org/jboss/ejb/metadata/spec/MethodPermissionMetaData.java (working copy)
                      @@ -103,7 +103,7 @@
                       *
                       * @param roles the roles.
                       */
                      - @XmlElement(name="role-name", type=NonNullLinkedHashSet.class)
                      + @XmlElement(name="role-name"/*, type=NonNullLinkedHashSet.class*/)
                       public void setRoles(Set<String> roles)
                       {
                       this.roles = roles;
                      Index: src/test/java/org/jboss/javaee/metadata/spec/ResourceInjectionMetaData.java
                      ===================================================================
                      --- src/test/java/org/jboss/javaee/metadata/spec/ResourceInjectionMetaData.java (revision 2575)
                      +++ src/test/java/org/jboss/javaee/metadata/spec/ResourceInjectionMetaData.java (working copy)
                      @@ -122,7 +122,7 @@
                       * @throws IllegalArgumentException for a null injectionTargets
                       */
                       //@SchemaProperty(name="injection-target", impl=NonNullLinkedHashSet.class, mandatory=false)
                      - @XmlElement(name="injection-target", type=NonNullLinkedHashSet.class, required=false)
                      + @XmlElement(name="injection-target", /*type=NonNullLinkedHashSet.class,*/ required=false)
                       public void setInjectionTargets(Set<ResourceInjectionTargetMetaData> injectionTargets)
                       {
                       if (injectionTargets == null)


                      It seems like there is no way to say which Collection impl we want to use with the standard JAXB annotations. The spec says:
                      "jaxb2.0" wrote:
                      If the property or field type is a parametric collection type, then
                      @XmlElement.type() must be DEFAULT.class or
                      collectionitem.class (since the type of the collection is already
                      known).


                      • 8. Re: JBossXB-2.0.0.CR5
                        aloubyansky

                        The only regression left is caused by the library dependency. Specifically, it's jboss-test. It's currently set to 1.0.4.GA with which the results:
                        tests: 638, errors: 13, failures: 9

                        If 1.0.0.GA is used there would be 8 errors and 9 failures. All expected.

                        • 9. Re: JBossXB-2.0.0.CR5
                          starksm64

                          I see 10/13 with 1.0.4.GA of org.jboss/test:
                          Tests run: 638, Failures: 10, Errors: 13, Skipped: 0

                          and 10/8 with 1.0.0.GA of jboss/test:
                          Tests run: 638, Failures: 10, Errors: 8, Skipped: 0

                          which are the 5 errors that are unexpected?

                          • 10. Re: JBossXB-2.0.0.CR5
                            aloubyansky

                            I meant the remaining 8 were expected, they are not a regression after merging. The 5 errors are IncompatibleClassChangeError.

                            • 11. Re: JBossXB-2.0.0.CR5
                              starksm64

                              The AbstractTestCase.checkThrowable changed from protected to public static in 1.0.4.GA, but a clean build should not have a problem. I don't see the failure from eclipse when I change its test version to 1.0.4.GA. Doing a mvn clean and install is down to 11 errors, and there are no IncompatibleClassChangeErrors.

                              • 12. Re: JBossXB-2.0.0.CR5
                                aloubyansky

                                What are those 11? I see 8:

                                org.jboss.test.xb.builder.object.attribute.test
                                Class Tests Errors Failures
                                IntegerUnitTestCase 2 1 1
                                StringUnitTestCase 2 1 1
                                
                                org.jboss.test.xml
                                Class Tests Errors Failures
                                AnnotatedPojoServerUnitTestCase 11 1 3
                                JbxbPojoServerUnitTestCase 11 1 0
                                RepeatedElementsUnitTestCase 1 1 0
                                
                                org.jboss.test.xb.builder.object.element.xmlelement.test
                                Class Tests Errors Failures
                                DefaultsUnitTestCase 2 1 0
                                NonDefaultsUnitTestCase 2 1 0
                                NoneUnitTestCase 2 1 0
                                


                                • 13. Re: JBossXB-2.0.0.CR5
                                  starksm64

                                   


                                  org.jboss.test.xb.builder.object.attribute.test.IntegerUnitTestCase.txt:Tests run: 2, Failures: 1, Errors: 1, Skipped: 0, Time elapsed: 0.531 sec <<< FAILURE!
                                  org.jboss.test.xb.builder.object.attribute.test.StringUnitTestCase.txt:Tests run: 2, Failures: 1, Errors: 1, Skipped: 0, Time elapsed: 0.532 sec <<< FAILURE!
                                  org.jboss.test.xb.builder.object.element.xmlelement.test.DefaultsUnitTestCase.txt:Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.547 sec <<<
                                  FAILURE!
                                  org.jboss.test.xb.builder.object.element.xmlelement.test.NonDefaultsUnitTestCase.txt:Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.547 sec <
                                  << FAILURE!
                                  org.jboss.test.xb.builder.object.element.xmlelement.test.NoneUnitTestCase.txt:Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.531 sec <<< FAIL
                                  URE!
                                  org.jboss.test.xb.builder.object.type.value.test.IntegerUnitTestCase.txt:Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.656 sec <<< FAILURE!
                                  org.jboss.test.xb.builder.object.type.value.test.StringUnitTestCase.txt:Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.515 sec <<< FAILURE!
                                  org.jboss.test.xml.AnnotatedPojoServerUnitTestCase.txt:Tests run: 11, Failures:3, Errors: 1, Skipped: 0, Time elapsed: 1.078 sec <<< FAILURE!
                                  org.jboss.test.xml.JbxbPojoServerUnitTestCase.txt:Tests run: 11, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.078 sec <<< FAILURE!
                                  org.jboss.test.xml.RepeatedElementsUnitTestCase.txt:Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.703 sec <<< FAILURE!



                                  • 14. Re: JBossXB-2.0.0.CR5
                                    aloubyansky

                                    That's 8 errors and 7 failures.
                                    I see the same plus

                                    Test set: org.jboss.test.xb.builder.object.mc.test.MapTestCase
                                    -------------------------------------------------------------------------------
                                    Tests run: 14, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.943 sec <<< FAILURE!
                                    testMapWithValue(org.jboss.test.xb.builder.object.mc.test.MapTestCase) Time elapsed: 0.02 sec <<< FAILURE!
                                    junit.framework.AssertionFailedError
                                     at junit.framework.Assert.fail(Assert.java:47)
                                     at junit.framework.Assert.assertTrue(Assert.java:20)
                                     at junit.framework.Assert.assertNotNull(Assert.java:220)
                                     at junit.framework.Assert.assertNotNull(Assert.java:213)
                                     at org.jboss.test.xb.builder.object.mc.test.AbstractMCTest.assertValue(AbstractMCTest.java:199)
                                     at org.jboss.test.xb.builder.object.mc.test.MapTestCase.testMapWithValue(MapTestCase.java:93)
                                     at org.jboss.test.xb.builder.object.mc.test.MapTestCase.testMapWithValue(MapTestCase.java:93)
                                    


                                    And I just committed the fix for proxy-factory-config issue. And I think the JBXB-109 can be closed now.

                                    1 2 Previous Next