On Jul 13, 2008, at 8:38 AM, Karan Malhi wrote:
Would it be neccessary to build the whole tree for the schema even
if i just
need part of the information from the xml file. For example, a
faces-config.xml contains information on validators, converters,
components,
managed-beans etc. I just need info on managedbeans. I was thinking
I would
just generate classes for managed-bean and its child elements and
forget
about the rest. Does anybody see any reason to generate classes for
stuff we
will not use?
It's possible to do it that way. Our default setting for the
JaxbJavaee is to fail if we see an element we don't understand, but
you could make a less strict version of the unmarshal method.
-David
On Mon, Jun 23, 2008 at 1:20 PM, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
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
--
Karan Singh Malhi
