Thanks for the excellent information.
We actually have been using element substitution. I was reluctant to use it
in a particular situation because it normally affects the generated method
name, but I had forgotten about using a property name customization to
override it. Also, because of the loss of functionality mentioned below.
So, for anyone else who is reading and doesn't follow, this is a possible
workaround for the situation:
New schema fragment:
(Compile with -extension argument for command line or extension="true"
attribute for Ant task.)
<complexType name="SomeType">
<sequence>
<element name="Something" type="int" />
</sequence>
</complexType>
<element name="SomeElement" type="this:SomeType" />
<element name="Container">
<complexType>
<sequence>
<element ref="this:SomeElement">
<annotation><appinfo>
<!-- Without this your
method name would be getSomeElement() instead of getInnerElement() -->
<jaxb:property
name="InnerElement" />
</appinfo></annotation>
</sequence>
</complexType>
</element>
The only down side to this, if I'm not mistaken is that you can no longer do
the following, which you could do previously:
SomeType someType = objFact.createSomeType();
someType.setSomething(5);
Container container = objFact.createContainer();
container.setInnerElement( someType );
So, it seems to currently be a trade-off until the new spec comes out.
Joe, if I misunderstood what you were saying, am wrong in any of the
examples, or if there is a better way to do this, please let me know.
Thanks again,
Brian Franklin
-----Original Message-----
From: Joseph Fialli [mailto:joseph.fialli_at_sun.com]
Sent: Wednesday, August 20, 2003 4:16 PM
To: users_at_jaxb.dev.java.net
Subject: Re: Setting one element into another element with the same type
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
For additional commands, e-mail: users-help_at_jaxb.dev.java.net