- 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 the latest version of
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.
|