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.

[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.

[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();
 }

[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.

[starksm64]

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

[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.

[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.

[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).

[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.

[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?

[aloubyansky]

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

[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.

[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

[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!

[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.