Radu,
Thanks for taking a look at this problem. I came up with a hack that
works, but I would prefer to go back to the original design. Here's a
reconstruction of my original code under my original design:
// Create and populate a Child1 instance.
Child1 child1 = Child1.Factory.newInstance();
child1.setAttr("attributeValue"); // Sets an attribute
child1.setText("some text"); // Set a subelementt
// Substitute the Child1 instance into the childrenList, which is
a list of
// type Parent. Assume an enclosing type has defined an element
// named children of complex type Children as specified in my
original
// posting.
Children childrenList = enclosingElement.addNewChildren();
Parent[] parentArray = new Parent[1];
parentArray[0] = child1;
childrenList.setChildrenArray[parentArray];
Since there was no easy way to directly create a Child1 instance in the
childrenList, I independently created a Child1 instance, put it into a
array, and substituted that array for the array in the childrenList. As I
mentioned in my original posting, the above code doesn't work. Since
then, I've come up with a hack that works but isn't very pretty. The hack
defines a choice type that causes a list of heterogeneous types that are
all subtypes of Parent to be generated by Xmlbeans.
<xs:complexType name="ChildrenHack" >
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element name="child1" type="Child1" />
<xs:element name="child2" type="Child2" />
</xs:choice>
</xs:complexType>
This hack cause Xmlbeans to generate code that I use as follows:
ChildrenHack childrenHack = enclosingElement.addNewChildrenHack()
Child1 child1 = childrenHack.addNewChild1();
...
I'm definitely interested in learning the correct way to populate a list
of general types with instances of specific subtypes. Save me from this
hack if you can!
Rich
