users@jaxb.java.net

Re: jaxb with jersey, can unmarshal, but not marshal

From: John G. Lussmyer <Cougar_at_CasaDelGato.Com>
Date: Thu, 15 Sep 2011 10:06:38 -0700

Sorry, I take that back. It's basically a useless change.
It seems to require that I work with JAXBElements, rather than objects
of the types I defined.
Marshall won't marshall an Options object.
And I think that Unmarshall will return a JAXBElement rather than an
Options.

On 9/15/2011 9:19 AM, John G. Lussmyer wrote:
> Thanks, that does seem to work. I thought I had tried that, and
> gotten an extra level of java name in there.
>
> Due to other problems with our systems right now, i can't actually run
> anything.
>
> Do the Element names actually show up anywhere in the XML?
>
> On 9/15/2011 2:43 AM, Wolfgang Laun wrote:
>>
>> <xs:element name="options" type="Options"/>
>> <xs:element name="option" type="Option"/>
>>
>> <xs:complexType name="Options">
>> <xs:sequence>
>> <xs:element name="Option" type="Option"
>> minOccurs="0" maxOccurs="unbounded" />
>> </xs:sequence>
>> </xs:complexType>
>>
>> <xs:complexType name="Option">
>> <xs:sequence>
>> <xs:element name="OptionId" type="xs:string"
>> minOccurs="1" maxOccurs="unbounded"/>
>> </xs:sequence>
>> </xs:complexType>
>>
>> It helps to define types and use them in element definitions (rather
>> than inline types). For clarity, I have changed element names to
>> lower case, but you can revert this, of course.
>>
>> There is no problem with having two "top level" elements, and one (or
>> both) can be an element somewhere in the other.
>>
>> Look at the generated ObjectFactory to see how createOption(s) is
>> overloaded so that you can construct top level elements as well as
>> subordinate elements. Also note where the XML element names are
>> defined for top levels and for subordinates.
>>
>> -W
>>
>>
>> On 15 September 2011 00:46, John G. Lussmyer <Cougar_at_casadelgato.com
>> <mailto:Cougar_at_casadelgato.com>> wrote:
>>
>> On 9/14/2011 11:04 AM, Wolfgang Laun wrote:
>>
>> This is too abstract for me - please provide something tangible.
>>
>> Generally speaking, it's possible to have a complexType
>> that's both a component (list element or scalar) of another
>> object and a solitary document type.
>>
>>
>> Okay, here's a trimmed down example:
>>
>> <xs:element name="Options">
>> <xs:complexType>
>> <xs:sequence>
>> <xs:element name="Option" type="Option" minOccurs="0"
>> maxOccurs="unbounded" />
>> </xs:sequence>
>> </xs:complexType>
>> </xs:element>
>>
>> <xs:complexType name="Option">
>> <xs:sequence>
>> <xs:element name="OptionId" type="OptionIdentifier" minOccurs="1"
>> maxOccurs="unbounded"/>
>> </xs:sequence>
>> </xs:complexType>
>>
>> I have some API's that take/return an "Options" and some that
>> take/return a "Option".
>> I can't make "Option" an xs:element, since that means it can't be
>> used as a type in "Options".
>>
>>
>
>
> --
> --
> John G. Lussmyer mailto:Cougar_at_CasaDelGato.Com
> Electric Vehicle Battery Monitoring Systems,http://www.CasaDelGato.com
>


-- 
--
John G. Lussmyer	  mailto:Cougar_at_CasaDelGato.Com
Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com