Manipulate JAXB to create IDREF Elements instead of JaxBElement<?> - xsd

I want to generate classes using maven-jaxb2-plugin.
My input xsd looks like the following:
<complexType>
<complexContent>
<restriction base="{http://www.w3.org/2001/XMLSchema}anyType">
<sequence>
<element name="ReferencedElementA" type="{http://www.w3.org/2001/XMLSchema}IDREFS" minOccurs="0" />
<element name="ReferencedElementB" type="{http://www.w3.org/2001/XMLSchema}IDREF"
maxOccurs="unbounded" minOccurs="0" />
</sequence>
</restriction>
</complexContent>
Please note, that i can't alter the schema as it is provided by an external customer!
This is the generated code:
#XmlList
#XmlElement(name = "ReferencedElementA")
#XmlIDREF
#XmlSchemaType(name = "IDREFS")
protected List<Object> referencedElementA;
#XmlElementRef(name = "ReferencedElementB", namespace = "ABC", type = JAXBElement.class, required = false)
protected List<JAXBElement<Object>> referencedElementB;
As you see, the "ReferencedElementB" is generated as a List> with the #XMLElementRef-Annotation.
What i want, is something like the following:
#XmlElement(name = "ReferencedElementB")
#XmlIDREF
#XmlSchemaType(name = "IDREF")
protected List<Object> referencedElementB;
Using the workaround from Blaise Doughan, i expanded my binding file with the following code:
<bindings node = ".//xs:element[#name='ReferencedElementB']">
<class ref="java.lang.Object"/>
</bindings>
This almost finished the job, generating code like this:
#XmlElement(name = "ReferencedElementB")
#XmlSchemaType(name = "IDREF")
protected List<Object> referencedElementB;
However, the #XmlIDREF-Annotation is still missing. This produces errors during marshalling.
I've tried to inject the missing annotation via annox-plugin:
<bindings node = ".//xs:element[#name='ReferencedElementB']">
<class ref="java.lang.Object"/>
<annox:annotate target="field">#javax.xml.bind.annotation.XmlIDREF</annox:annotate>
</bindings>
But the generation fails with
compiler was unable to honor this annox:annotate customization. It is attached to a wrong place, or its inconsistent with other bindings
Once again, i'm not able to alter the input xsd.
Thank you in advance!

Please note, that i can't alter the schema as it is provided by an external customer!
I read this all the time here on SO and I always wonder - why? Why can't you alter the schema?
Well, of course you can alter the schema prior to compilation. Take the original schema and apply a patch/XSLT/whatever to modify it. As long as the result structurally matches the original schema, it is fine.
Consider your case: you use tricks and workarounds to effectively hack the generated code. How much better is it compared to modifying the schema prior to compilation? I don't think it is better at all. It is more complicated, error-prone and at the end you cannot say that your generated code is the reflection of your schema. Effectively, you do not have a schema for your code. You can't even say if your hacked generated code is an adequate reflection of the original schema.
Modifying the schema prior to compilation is quite easy. You can easily compare original vs. modified and see if changes are compatible or not. Generation is straightforward, no need for hacks and workarounds.
Now to your question.
The binding
<annox:annotate target="field">#javax.xml.bind.annotation.XmlIDREF</annox:annotate>
looks fine for me. For some reason it is not considered during schema compilation, this is why you get the error.
Hard to say why it is not considered. I'd try the following:
Check that you actually include/turn on the JAXB2 Basics Annotate plugin in your compilation:
<plugin>
<groupId>org.jvnet.jaxb2.maven2</groupId>
<artifactId>maven-jaxb2-plugin</artifactId>
<configuration>
<extension>true</extension>
<args>
<arg>-Xannotate</arg>
</args>
<plugins>
<plugin>
<groupId>org.jvnet.jaxb2_commons</groupId>
<artifactId>jaxb2-basics-annotate</artifactId>
</plugin>
</plugins>
</configuration>
</plugin>
Put the customization element in its own bindings element. Maybe it does not work together with class for some reason.
I don't see more at the moment should work.
If it does not help, please send me a PR with a minimal reproducing project here:
https://github.com/highsource/jaxb2-annotate-plugin-support
under i/idrefs. I will take a look.
Disclaimer: I am the author of annox, jaxb2-annotate-plugin and maven-jaxb2-plugin.

Related

cXML to java bindings issues

Issue: Unable to create java classes from cXML.dtd using java xjc
version I am using is 1.2.032
command used : xjc -dtd cXML.dtd
Error :
parsing a schema...
[ERROR] Property "Name" is already defined. Use <jaxb:property> to resolve th
is conflict.
Issue 1 : Line number around 573
issue is with the "name" as its duplicate (element as well as attribute).
issue 2:
ShippingPaymentMethod,TermsOfDeliveryCode,TransportTerms uses "value" which is causing duplicate definations.
Solution as I understand==
I need custom binding.xml .. I tried various ways but unable to create correct binding.xml to solve this issue. once I have correct xml I can use following command to create generated classes.
xjc -b binding.xml -dtd cXML.dtd
What I help I need
please provide correct binding.xml if possible
Is there any alternate way to generate java mappings for this cXML
Is there possibilities to have XSD and then have java mapping from XSD?
Please suggest.
FYI: you can also solve this with an external jax-b binding file that looks like this:
<xml-java-binding-schema xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc">
<element name="ReturnData" type="class">
<attribute name="name" property="nameAttribute"/>
</element>
<element name="ShippingPaymentMethod" type="class">
<attribute name="value" property="valueAttribute"/>
</element>
<element name="TermsOfDeliveryCode" type="class">
<attribute name="value" property="valueAttribute"/>
</element>
<element name="TransportTerms" type="class">
<attribute name="value" property="valueAttribute"/>
</element>
</xml-java-binding-schema>
The CXML spec is VERY annoying to generate JAX-B classes for because of their continued use of DTD over XML schema. This is especially annoying if you want to use the other DTDs (Invoice, Catalog, Fulfill) as they each redefine all the common elements but use their own versions of the cxml.requests, cxml.messages, cxml.responses entities
Issue Resolved by myself. did following steps.. may be useful for others
Renamed "name" element "ReturnData" in Cxml.dtd
Renamed "value" attr from TransportTerms,ShippingPaymentMethod,and TermsOfDeliveryCode in Cxml.dtd
Created java classes using
xjc -dtd cXML.dtd
4.in Generated java classes changed xml annotation back to original.
So method names will be different but it will read and write correct XML.

How do I change the case of XSD element name when generated as #XmlElement via xjc

I have a schema where element names are defined in PascalCase eg:
<xsd:element name="EmployeeName" minOccurs="0" maxOccurs="1">
But I would like this to generate as:
#XmlElement(name = "employeeName")
I know this sounds slightly strange but it will then allow me to use Jackson JAXB annotation support to have my JSON generated in camelCase.
Is this possible?
Yes, it is possible to change the XML element name to (nearly) whatever you want by way of the annotation directives.
In this example, "price" is renamed to "itemprice". Java is not case insensitive, so your camel casing will be honored.
//Example: Code fragment
public class USPrice {
#XmlElement(name="itemprice")
public java.math.BigDecimal price;
}
<!-- Example: Local XML Schema element -->
<xs:complexType name="USPrice"/>
<xs:sequence>
<xs:element name="itemprice" type="xs:decimal" minOccurs="0"/>
</sequence>
</xs:complexType>
This example comes from the JAXB javadocs.
Note that JAXB support has a few "how to use it" workflows, "XSD to generate supporting Java classes", and "Java classes to generate an XSD". I prefer the latter, but you may be using the former. If you are, then you need to alter your XSD to have camelCase element names there.
There is no "use my XSD to generate Java classes, but with some overrides" workflow. Perhaps that's where the confusion comes from. Likewise, there is no "Use Java class annotations to generated XSD documents, but with some overrides". What you specify is going to be what you get, name-wise.

cvc-elt.1: Cannot find the declaration of element 'MyElement'

I'm trying to validate a really simple xml using xsd, but for some reason I get this error.
I'll really appreciate if someone can explain me why.
XML File
<?xml version="1.0" encoding="utf-8"?>
<MyElement>A</MyElement>
XSD File
<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.example.org/Test"
xmlns:tns="http://www.example.org/Test"
elementFormDefault="qualified">
<simpleType name="MyType">
<restriction base="string"></restriction>
</simpleType>
<element name="MyElement" type="tns:MyType"></element>
</schema>
Your schema is for its target namespace http://www.example.org/Test so it defines an element with name MyElement in that target namespace http://www.example.org/Test. Your instance document however has an element with name MyElement in no namespace. That is why the validating parser tells you it can't find a declaration for that element, you haven't provided a schema for elements in no namespace.
You either need to change the schema to not use a target namespace at all or you need to change the instance to use e.g. <MyElement xmlns="http://www.example.org/Test">A</MyElement>.
After making the change suggested above by Martin, I was still getting the same error. I had to make an additional change to my parsing code. I was parsing the XML file via a DocumentBuilder as shown in the oracle docs:
https://docs.oracle.com/javase/7/docs/api/javax/xml/validation/package-summary.html
// parse an XML document into a DOM tree
DocumentBuilder parser = DocumentBuilderFactory.newInstance().newDocumentBuilder();
Document document = parser.parse(new File("example.xml"));
The problem was that DocumentBuilder is not namespace aware by default. The following additional change resolved the issue:
// parse an XML document into a DOM tree
DocumentBuilderFactory dmfactory = DocumentBuilderFactory.newInstance();
dmfactory.setNamespaceAware(true);
DocumentBuilder parser = dmfactory.newDocumentBuilder();
Document document = parser.parse(new File("example.xml"));
I had this error for my XXX element and it was because my XSD was wrongly formatted according to javax.xml.bind v2.2.11 . I think it's using an older XSD format but I didn't bother to confirm.
My initial wrong XSD was alike the following:
<xs:element name="Document" type="Document"/>
...
<xs:complexType name="Document">
<xs:sequence>
<xs:element name="XXX" type="XXX_TYPE"/>
</xs:sequence>
</xs:complexType>
The good XSD format for my migration to succeed was the following:
<xs:element name="Document">
<xs:complexType>
<xs:sequence>
<xs:element ref="XXX"/>
</xs:sequence>
</xs:complexType>
</xs:element>
...
<xs:element name="XXX" type="XXX_TYPE"/>
And so on for every similar XSD nodes.
I got this same error working in Eclipse with Maven with the additional information
schema_reference.4: Failed to read schema document 'https://maven.apache.org/xsd/maven-4.0.0.xsd', because 1) could not find the document; 2) the document could not be read; 3) the root element of the document is not <xsd:schema>.
This was after copying in a new controller and it's interface from a Thymeleaf example. Honestly, no matter how careful I am I still am at a loss to understand how one is expected to figure this out. On a (lucky) guess I right clicked the project, clicked Maven and Update Project which cleared up the issue.
To expand upon the top answer. If you're using Java Web Services (JAX-WS) annotations to define your services, like in this example:
#WebService(..., targetNamespace = "http://bar.foo.com/")
Then make sure that your SOAP request has exactly the same namespace as defined in your annotation:
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:foo="http://bar.foo.com/">
<soapenv:Header/>
<soapenv:Body>
<foo:someRequest>
...
</foo:someRequest>
</soapenv:Body>
</soapenv:Envelope>
The targetNamespace in your annotation and the xmlns:foo property in the XML request must match! Literally every character (including whitespace) must match. Also don't forget to put the / at the end as well (it's a very common mistake).

using xsd attributes in another xsd as tag/tag-parameters

I wanted to know if it is possible or not:
a.xsd :
<attribute name="aa" type="String">
b.xsd
<element name="bb" aa="pan" type="string"/>
or
<aa name="pan" type="string">
basically i am trying to find out if we can use the xsd attributes inside another xsd as tags or tag-parameters.
i am new to this xsd world if it is wrong use-case then also please post your views.
I am not clear on what you are trying to accomplish, but the xsd:element element has a set of recognized attributes. It won't do you any good to try to make up attributes to add to it.

Using dom4j DOMDocument to feed validator.validate(DOMSource) fails in java 1.6 (xsi:noNamespaceSchemaLocation is not allowed), works in 1.5

Using dom4j DOMDocument to feed validator.validate(DOMSource) fails in java 1.6 (with xsi:noNamespaceSchemaLocation is not allowed to appear in root element), works in 1.5
I'm finding the following problem quite intractable (OK, that's an understatement) - any insights will be appreciated. Currently it seems like the best idea is to drop dom4j in favour of e.g. XOM (http://stackoverflow.com/questions/831865/what-java-xml-library-do-you-recommend-to-replace-dom4j).
I've been validating in memory XML created from dom4j 'new DOMDocument()' - but this will not work with Java 6.
The following call to validate(source) of a dom4j (1.6.1) DOMDocument derived DOMSource works with Java 1.5.x but fails with Java 1.6.x:
public void validate() throws Exception {
SchemaFactory schemaFactory = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);
schemaFactory.setErrorHandler(null);
Schema schemaXSD = schemaFactory.newSchema(new URL(getSchemaURLString()));
Validator validator = schemaXSD.newValidator();
DOMSource source = new DOMSource(getDocument());
validator.validate(source);
}
getSchemaURLString() is also used to add the xsi:noNamespaceSchemaLocation attribute to the root node, i.e.:
xsi:noNamespaceSchemaLocation="http://localhost:8080/integration/xsd/fqlResponseSchema-2.0.xsd"
The exception follows:
Exception: org.xml.sax.SAXParseException: cvc-complex-type.3.2.2: Attribute 'xsi:noNamespaceSchemaLocation' is not allowed to appear in element 'specialfields'.;
complex-type.3.2.2: Attribute 'xsi:noNamespaceSchemaLocation' is not allowed to appear in element 'specialfields'.
at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:195)
at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:131)
at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:384)
at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:318)
at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator$XSIErrorReporter.reportError(XMLSchemaValidator.java:417)
at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.reportSchemaError(XMLSchemaValidator.java:3182)
at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.processAttributes(XMLSchemaValidator.java:2659)
at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.handleStartElement(XMLSchemaValidator.java:2066)
at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.startElement(XMLSchemaValidator.java:705)
at com.sun.org.apache.xerces.internal.jaxp.validation.DOMValidatorHelper.beginNode(DOMValidatorHelper.java:273)
at com.sun.org.apache.xerces.internal.jaxp.validation.DOMValidatorHelper.validate(DOMValidatorHelper.java:240)
at com.sun.org.apache.xerces.internal.jaxp.validation.DOMValidatorHelper.validate(DOMValidatorHelper.java:186)
at com.sun.org.apache.xerces.internal.jaxp.validation.ValidatorImpl.validate(ValidatorImpl.java:104)
at javax.xml.validation.Validator.validate(Validator.java:127)
Here's the start of the XML - generated after disabling the call to validator.validate(source):
<?xml version="1.0" encoding="utf-8"?>
<meetings xsi:noNamespaceSchemaLocation="http://localhost:8080/integration/xsd/fqlResponseSchema-2.0.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
.............
</meetings>
And of the XSD:
<?xml version="1.0" encoding="utf-8" ?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
<xs:element name="meetings">
<xs:complexType>
<xs:choice>
<xs:sequence>
<xs:element minOccurs="0" maxOccurs="1" ref="summary" />
<xs:element minOccurs="0" maxOccurs="unbounded" ref="meeting" />
</xs:sequence>
<xs:element ref="error" />
</xs:choice>
</xs:complexType>
</xs:element>
<xs:element name="summary">
................
So my root element is being rejected because it contains a xsi:noNamespaceSchemaLocation attribute. And the schema itself does not specify that as a valid attribute of my root element?
At this point it seems to me that I need to give up on dom4j for this task and switch to one of the other solutions, for example as outlined here:
But I'd like to know what I've done wrong at any rate!
Thanks in advance.
I had the same issue, and I found the following documentation at
http://www.ibm.com/developerworks/xml/library/x-javaxmlvalidapi/index.html
Validate against a document-specified schema
Some documents specify the schema they expect to be validated against,
typically using xsi:noNamespaceSchemaLocation and/or
xsi:schemaLocation attributes like this:
<document xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://www.example.com/document.xsd">
...
If you create a schema without specifying a URL, file, or source, then
the Java language creates one that looks in the document being
validated to find the schema it should use. For example:
SchemaFactory factory = SchemaFactory.newInstance("http://www.w3.org/2001/XMLSchema");
Schema schema = factory.newSchema();
However, normally this isn't what you want. Usually the document
consumer should choose the schema, not the document producer.
Furthermore, this approach works only for XSD. All other schema
languages require an explicitly specified schema location.
The reason seems to be that non-namespace aware JAXP SAXParser is being created and used (see Link).
And solution for different libs I found at www.edankert.com.

Resources