Never mind about the "trade-off" comment. I did a quick test, and I
see that it automatically wraps the type in an element with the
referenced element's name. That's quite fortunate.
Brian Franklin
On Wednesday, August 20, 2003, at 05:32 PM, Franklin, Brian wrote:
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
For additional commands, e-mail: users-help_at_jaxb.dev.java.net