Franklin, Brian wrote:
>I believe this issue (or at least one similar to it) has been brought up in
>previous threads (1), but I wanted to confirm something and ask the team how
>this will work in the future. Questions are near the bottom.
>
>Kohsuke gave a pretty simple example previously that I *think* is the same
>thing, but just to be sure, here's an example that I know behaves strangely.
>
>Schema fragment:
> <complexType name="SomeType">
> <sequence>
> <element name="Something" type="int" />
> </sequence>
> </complexType>
> <element name="SomeElement" type="this:SomeType" />
>
> <element name="Container">
> <complexType>
> <sequence>
> <element name="InnerElement"
>type="this:SomeType" />
> </sequence>
> </complexType>
> </element>
>
>Sample code fragment:
>
> SomeType someType = objFact.createSomeElement();
> someType.setSomething(5);
>
> Container container = objFact.createContainer();
> container.setInnerElement( someType );
>
> marshaller.marshal( ...output... );
>
>Resulting output fragment:
>
> <Container>
> <InnerElement>
> <SomeElement>
> <Something>5</Something>
> </SomeElement>
> </InnerElement>
> </Container>
>
>
>Questions:
>
>1) Is this how this will behave in the future?
>
The JAXB 1.0 Specification definitely does not specify this marshalled
behavior.
You are observing a behavior in the current implementation.
The JAXB property setter method definitely allows for an instance of
javax.xml.bind.Element to be
set on a JAXB property, this behavior was necessary to support a JAXB
property representing
a wildcard <xsd:any>, or in the future, to support element substitution
groups. Both these
cases required the JAXB setter to be able to dynamically provide an
element name to use for validation and marshalling.
The example above demonstrates when the schema has a fixed element name
for the JAXB
property InnerElement representing a local child element
AND the application also dynamically provides an element name by calling
the JAXB setter property for InnerElement with an instance of
javax.xml.bind.Element.
We plan to address this hole in the JAXB 1.0 Specification that you have
pointed out
(we have been aware of it) and identify a user-friendly, deterministic
solution in
the JAXB 2.0 expert group.
>2) Will the inclusion of type substitution change how this looks/behaves?
>
>
Type substitution does not allow for an element name to be changed for
JAXB property.
Actually, element substitution group support is the interesting feature
where a JAXB setter
can take as a parameter an element instance with an element name
different than is specified in the
constraining schema AND the setter provided element name REPLACES the
schema element reference.
This support is already implemented in JAXB 1.0.1 with xjc -extension
mode and it
does not suffer from the issue that your case identifies. For this
case, the implementation
is always allowing the element name provided by the JAXB setter to override
the schema reference to the element substitution group header element,
thus, both
element names are not output by the marshaller.
>3) If the ability to "T getType()" and "setType(T)" of an element is
>implemented in the future, will this be handled automatically in this case?
>
Automatically handling this case or throwing an exception when the JAXB
setter
method is called with a javax.xml.bind.Element instance are two possible
solutions.
If the automated handling can not be deterministically specified,
throwing an
exception would be the preferable path.
Thanks for your feedback.
-Joe
>4) If this is going to continue to behave this way, shouldn't setting an
>Element into another Element field of the same type throw an exception or
>something?
>
>
>Thanks, as always, for your time and hard work.
>
>
>Brian Franklin
>
>----
>Footnotes: (following the trend that Ryan seems to be pushing)
>
>(1) For those of you who want to search the archives, the following topics
>seemed to be at least somewhat relevant to the issue:
> "Marshalling a content sub-tree"
> "Help!! Elements & types"
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
>For additional commands, e-mail: users-help_at_jaxb.dev.java.net
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
For additional commands, e-mail: users-help_at_jaxb.dev.java.net