Yes, that looks like the correct conversion. Jaxb does not enforce
(or even check) that elements are in the correct order when reading a
document, so the ordering declaration in the generated bean won't
effect you.
-dain
On Jun 22, 2008, at 3:12 PM, Karan Malhi wrote:
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
