Han Ming Ong wrote:
> Guys,
>
> Given the following schema snippets:
>
> <xs:element name="app">
> <xs:complexType>
> <xs:sequence>
> <xs:element ref="comment-before-root" minOccurs="0"
> maxOccurs="unbounded"/>
> <xs:element ref="desc" maxOccurs="unbounded" />
> </xs:sequence>
> </xs:complexType>
> </xs:element>
>
> <xs:element name="desc">
> <xs:complexType>
> <xs:sequence>
> ...
> </xs:sequence>
> </xs:complexType>
> </xs:element>
>
> I get the following API for returning desc in the interface AppType:
>
> DescType[] getDesc();
>
> Of course the interface DescType inherits from interface Desc. I
> don't care about the rationale behind *not* returning Desc[] in the RI
The rationale for the method signature returning the type of the
element is very important
for the general case. Future support for type substitution requires this
return type.
Example:
Given following XML Schema:
<complexType name="Base"> ....
<complexType name="Derived"> <!-- derives by extension from Base -->
<element name="anElement" type="Base"/>
Any property referencing AnElement is bound to the following methods:
Base getAnElement()
void setAnElement(Base value)
Here are the Java interfaces for above.
public interface Base ....
public interface Derived implements Base ..
public interface AnElement extends Base, javax.xml.bind.Element ...
It is important that one can handle instances of both Base and Derived
for the JAXB property, AnElement. Following are legal instances
of anElement in an xml document.
<anElement xsi:type="Derived"> ..Content model for Base and
Derived..</anElement>.
<anElement>...Content model for Base ... </anElement>
If the signature was constrained to the element interface, one would not
be able
to return an instance of Derived since it is not an instance of AnElement.
It is true that your case with anonymous complex type definition that
does not derive
from anything does not allow for type substitution. However, there is a
wish to not generate different looking JAXB Java properties to reflect the
underlying XML as often as possible.
>
> but I would like to know if there is a way I could customize it in JAXB
> generation?
The current implementation is not capable of customizing the value returned
by a JAXB property.
In the interest of evaluating the capability that you need and
what granularity it should be at, could you provide the rationale for
why you need this capability.
It would be possible to consider returning an instance of Desc for your
example;
however, it probably would be preferable for the signature to remain as is.
Otherwise, it would introduce a JAXB customization that would allow
the customizer to easily restrict the XML instance documents that the
JAXB method
signatures could handle.
-Joe Fialli, Sun Microsystems
>
>
> Naively changing the codes manually on my part result in
> java.lang.ArrayStoreException eventually.
>
> Thanks much, Han Ming