But a choice does not require elements to be in a certain order whereas a
sequence does. Here is how I changed from a choice to a sequence (notice the
propOrder attribute of the @XmlType annotation. I am not sure if i did it
correctly or not, could you please confirm if the below is the correct way
of doing it
Here is the original xsd :
<!-- **************************************************** -->
<xsd:complexType name="faces-configType">
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element name="application"
type="javaee:faces-config-applicationType"/>
<xsd:element name="factory"
type="javaee:faces-config-factoryType"/>
. . . . . . . . .
. . . . . . . . .
<xsd:element name="faces-config-extension"
type="javaee:faces-config-extensionType"
minOccurs="0"
maxOccurs="unbounded"/>
</xsd:choice>
. . . . . . . . .
</xsd:complexType>
<!-- **************************************************** -->
Here is what I changed it to:-
<!-- **************************************************** -->
<xsd:complexType name="faces-configType">
<xsd:sequence >
<xsd:element name="application"
type="javaee:faces-config-applicationType"
minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="factory"
type="javaee:faces-config-factoryType"
minOccurs="0" maxOccurs="unbounded"/>
. . . . . . . . .
. . . . . . . . .
<xsd:element name="faces-config-extension"
type="javaee:faces-config-extensionType"
minOccurs="0"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<!-- **************************************************** -->
And here is the final output of FacesConfigType.java
<!-- **************************************************** -->
@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "faces-configType", propOrder = {
"application",
"factory",
"component",
"converter",
"managedBean",
"navigationRule",
"referencedBean",
"renderKit",
"lifecycle",
"validator",
"facesConfigExtension"
})
public class FacesConfigType {
protected List<FacesConfigApplicationType> application;
protected List<FacesConfigFactoryType> factory;
protected List<FacesConfigComponentType> component;
protected List<FacesConfigConverterType> converter;
@XmlElement(name = "managed-bean")
protected List<FacesConfigManagedBeanType> managedBean;
@XmlElement(name = "navigation-rule")
protected List<FacesConfigNavigationRuleType> navigationRule;
@XmlElement(name = "referenced-bean")
protected List<FacesConfigReferencedBeanType> referencedBean;
@XmlElement(name = "render-kit")
protected List<FacesConfigRenderKitType> renderKit;
protected List<FacesConfigLifecycleType> lifecycle;
protected List<FacesConfigValidatorType> validator;
@XmlElement(name = "faces-config-extension")
protected List<FacesConfigExtensionType> facesConfigExtension;
<!-- **************************************************** -->
On Fri, Jun 20, 2008 at 1:57 PM, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
> I also typically replace choice groups with a sequence of optional
> elements. When JAXB generates java code for choice groups, it creates a
> List<Object> instead of fields for each choice, which just annoying to work
> with. JAXB will parse the documents file with the change.
>
> -dain
>
>
> On Jun 20, 2008, at 7:29 AM, Karan Malhi wrote:
>
>
>>> There's really nothing in the docs about cheating at this level.
>>>
>>
>> :)
>>
>> Best bet is to try and trim the schema down to only what you really want
>>> to generate. You may have to hack on the resulting java code a bit to
>>> wire
>>> it into any existing objects we already have jaxb objects for. If you're
>>> lucky there won't be too much overlap or any at all.
>>>
>>> Hmm... I didnt realize I might have to tweak the generated code. Good to
>>>
>> know this.
>>
>>
>> --
>> Karan Singh Malhi
>>
>
>
--
Karan Singh Malhi
