- The JAXB Specification does not require full W3C XML Schema support in version
1.0. Please refer to Appendix E.2 for full details.
- Specifying large values for maxOccurs attributes can cause
java.lang.OutOfMemoryError
- The @enableFailFastCheck optional customization of
<jaxb:globalBindings> is not implemented yet.
- Specifying HTML markup tags within <jaxb:javadoc> customizations
requires you to enclose the data within a CDATA section or escape all
left angle brackets using "<". See
XML 1.0 2nd
Edition for more detail. In addition, you must include <body> tags
when specifying javadoc under the <jaxb:package> customization.
- The RI has some difficulty handling fixed attributes. For example, the validator
does not detect errors when the XML data has a value different from the fixed
value defined for the attribute in the schema.
- Compilations of sufficiently large and/or complex schemas may fail with
java.lang.StackOverflowError. Try working around this problem by
increasing the native stack size. For example, to increase the stack size to 2 megabytes:
java -Xss2m
If you run out of memory, try increasing the maximum memory
size. For example, to increase the maximum memory to 128 megabytes:
java -Xmx128m
- The JAXB Specification currently does not address the thread safety of any of
the runtime classes. In the case of the Sun JAXB RI, the JAXBContext
class is thread safe, but the Marshaller, Unmarshaller,
and Validator classes are not thread safe.
- In rare cases, you may see: "java.lang.Error: unable to load schema-for-schema
for W3C XML Schema" while attempting to compile your schemas.
If you see this error, try updating your version of J2SE SDK.
- If you are getting error messages like:
[ERROR] Unable to load "CustomString" Is this class available in the classpath?
line 15 of test.xsd
Make sure that the classes you are referencing in your <jxb:javaType> and
<xjc:superClass> customizations are compiled and added to the classpath
via the "-classpath" command-line option for the
xjc command.
- A new list of compiler
restrictions has been added to the binding compiler documentation.
- Under certain conditions, xjc may give this warning:
Unable to validate your schema. Most likely,
the JVM has loaded an incompatible XML parser
implementation. You should fix this before
relying on the generated code.
Please see the release notes for details.
The usual condition is that a version of xercesImpl.jar (as might be bundled
with ant, an IDE, or an AppServer e.g.) is in your CLASSPATH before the one
shipped with the Java WSDP. This deters xjc from resolving dependencies it has
on internal Xerces APIs. In previous releases of JAXB, this error condition
would manifest itself as an IllegalAccessError.
To fix this, make sure jwsdp-1.6/jaxp/lib/endorsed/xercesImpl.jar
precedes any other version of Xerces in your CLASSPATH. Otherwise, xjc can't
validate your schema and you shouldn't rely on the generated code.
- The fact that javax.xml.bind.util.JAXBSource derives
from javax.xml.transform.sax.SAXSource is an implementation detail. Thus in
general applications are strongly discouraged from accessing methods defined on
SAXSource. In particular, the setXMLReader and setInputSource
methods shall never be called. The XMLReader object obtained by the
getXMLReader method shall be used only for parsing the InputSource
object returned by the getInputSource method. Similarly the InputSource
object obtained by the getInputSource method shall be used only for being
parsed by the XMLReader object returned by the getXMLReader.
For javax.xml.bind.util.JAXBResult, applications are strongly discouraged
from accessing methods defined on javax.xml.transform.sax.SAXResult. In
particular it shall never attempt to call the setHandler,
setLexicalHandler, and setSystemId methods.
These limitations will be incorporated into the next version of the javadocs.
|