Collections with interfaces

[starksm64]

When I switched the EnterpriseBeansMetaData to extend AbstractMappedMetaData instead of AbstractMappedMetaData, the child elements are lost:

@XmlType(name="enterprise-beansType")
public class EnterpriseBeansMetaData
 extends AbstractMappedMetaData<IEnterpriseBeanMetaData>
 implements IEnterpriseBeansMetaData
{

Its the implementations of IEnterpriseBeanMetaData that would have the annotations:

@JBossXmlModelGroup(
 kind=JBossXmlConstants.MODEL_GROUP_CHOICE,
 particles={
 @JBossXmlModelGroup.Particle(element=@XmlElement(name="session"), type=SessionBeanMetaData.class),
 @JBossXmlModelGroup.Particle(element=@XmlElement(name="entity"), type=EntityBeanMetaData.class),
 @JBossXmlModelGroup.Particle(element=@XmlElement(name="message-driven"), type=MessageDrivenBeanMetaData.class)})
public abstract class EnterpriseBeanMetaData extends NamedMetaDataWithDescriptionGroup
 implements Environment,
 IEnterpriseBeanMetaData
{

How would I propagate this info up to the EnterpriseBeansMetaData class?

[starksm64]

This is due to this code block not checking the localPropertyType for 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.equals(propertyType))
 { // the localPropertyType was not overriden previously so use the collection parameter type
 localPropertyType = typeArg;
 }
 }
 }

when the property type is a parameterized interface, the localPropertyType refers to the real type that carries the annotation information. Changing the check to be:

 else if (propertyType.isCollection() && ((ClassInfo) localPropertyType).getUnderlyingAnnotation(XmlType.class) == null)
 {

gets the parsing to occur as I expect.

[aloubyansky]

It introduced regression in the testsuite. It used be 8 errors and 8 failures. Now it's
Tests run: 651, Failures: 7, Errors: 180, Skipped: 0

[starksm64]

Something else caused the regressions as I saw the same error counts with/without this change.

[aloubyansky]

I am sure it's this change.
I am looking into the issue with the interfaces. To start, I added @XmlTransient to getEnterpriseBeansMetaData on IEnterpriseBeanMetaData.

[starksm64]

Ok

[wolfc]

I was also looking at trying to add XmlTransient to getEnterpriseBeansMetaData on IEnterpriseBeanMetaData. The actual problem is that JBossMetaData.setEnterpriseBeans doesn't define a class. I've fixed that.

[aloubyansky]

There should be a CCE since XB uses ArrayList as the default collection impl.

[aloubyansky]

The CCE happens if I rollback Scott's change. It's the same problem with collections we had, i.e. we cannot specify the collection impl we want to use currently. It's easy to fix though by adding a new annotation.

[aloubyansky]

I added @JBossXmlCollection annotation and bound JBossMetaData.enterpriseBeans to JBossEnterpriseBeansMetaData.

[starksm64]

With your changes these are the errors I'm seeing:

Tests run: 651, Failures: 20, Errors: 9, Skipped: 0

Is that what you have?

[starksm64]

I thought this was working, but when I updated another workspace the same incompatible type was seen. I checked the JBossMetaData but did not see the @JBossXmlCollection in use, so I added that and the tests are working again. Perhaps you forgot to commit this or it failed due to other changes. I have checked these changes in.

[aloubyansky]

Yes, perhaps, it failed to commit. Thanks for fixing.

[starksm64]

I needed to add an elementType to JBossXmlCollection to allow for the specification of the collection element type for collections of unparameterized interfaces like:

@XmlType(name="service-refType")
public class JBossServiceReferencesMetaData
 extends AbstractMappedMetaData<IServiceReferenceMetaData>
 implements IServiceReferencesMetaData
{
...

so one can define both the collection class, and its concrete element type:

 @JBossXmlCollection(type=JBossServiceReferencesMetaData.class, elementType=JBossServiceReferenceMetaData.class)
 @XmlElement(name="service-ref")
 public void setServiceReferences(IServiceReferencesMetaData serviceReferences)
 {
 this.serviceReferences = (JBossServiceReferencesMetaData) serviceReferences;
 }

Can you check its use in the JBossXBNoSchemaBuilder? There was one location where I was not clear on whether this should override the localPropertyType.

[aloubyansky]

Collection item should be specified with @XmlElement.type. If it didn't work it's a bug.