Design Documentation: JAXB RI Extensions
In the JAXB RI, developed by Sun, there are a series of "proprietary" extensions that are available to provide advanced JAXB functionality outside of the JAXB spec (these extension classes reside in the com.sun.xml.bind and com.sun.internal.xml.bind packages).
This page will track the various JAXB Extensions that we want to bring into MOXy.
Jan. 2012: Other extension properties: http://jaxb.java.net/2.2/docs/vendorProperties.html
Our intent is to support these extensions as is, so that MOXy can be a drop in replacement for the JAXB RI.
The following are the outstanding items being targeted for EclipseLink 2.3.3 and 2.4.0.
- Bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=372403
- Added for the benefit of Hibernate users
- Difficult to implement, no documentation, can be replaced by @XmlJavaTypeAdapter
- Bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=372404
- Can't get it to work in RI or Metro!
- mgrebac: "You can have a look under cycle-recovery sample in jaxb sources or jaxb release artifacts."
The following items have been checked into EclipseLink 2.3.3 and 2.4.0.
Test Get/Set For All Properties
- We need to ensure that we test getting all these properties as well as setting them.
- COMPLETE : org.eclipse.persistence.testing.jaxb.properties.PropertyTestCases
- Documentation: http://wiki.eclipse.org/EclipseLink/Development/355766
- Bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=355766
- Would give the user more information after unmarshalling, could be useful in WSDL environments, or other times when JAXB XML data may be embedded within other XML
- Background Info: http://jaxb.java.net/2.2/docs/vendorProperties.html#prefixmapper
- Bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=357266
- Allows the user to customize the namespace prefixes that are generated
- Could create our own NamespacePrefixMapper that users could subclass
- Custom Mapper would be provided via Marshaller properties
- Documentation: http://wiki.eclipse.org/EclipseLink/Development/360249
- Bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=360249
- Exampe: http://weblogs.java.net/blog/kohsuke/archive/2005/08/pluggable_ididr.html
- IDResolver works for Kohsuke's first example (Distinctive Symbol Spaces) but the combination with Unmarshall.Listener doesn't seem to work (Scoped Symbol Spaces)
- mgrebac: "Need to look into this one further."
- Background Info: http://jaxb.java.net/2.2/docs/vendorProperties.html#indent
- Documentation: http://wiki.eclipse.org/EclipseLink/Development/370574
- Bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=370574
- Allows the user to customize the indenting that happens in marshalled documents
- Background Info: http://jaxb.java.net/2.2/docs/vendorProperties.html#charescape
- Documentation: http://wiki.eclipse.org/EclipseLink/Development/370589
- Bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=370589
- Allows the user to customize the escaping of special characters
- Not applicable when marshalling to: XMLStreamWriter, XMLEventWriter, ContentHandler, Node
XML Declaration Control
- Background Info: http://jaxb.java.net/2.2/docs/vendorProperties.html#xmldecl
- Same as Marshaller.JAXB_FRAGMENT
The following items are of low priority and will be pushed out to a future release.
- Allows for more flexible mapping (?)
- Doesn't work if the field to override is not named "content", customization doesn't work (RI)
- mgrebac: "The above annotation was actually used only for a very specific case of supporting usecase with XmlMixed, and is actually even not expected to be used outside of xjc."
- Seems to be mainly used internally by the RI
- Interface only defines get methods... is user resonsible for setting up com.sun.xml.bind.v2.runtime.Location objects? Is this even meant to be a user-feature?
- mgrebac: "No, this is as well not meant to be user feature, is usable for xjc itself and plugins to point to correct source when there is a failure."
- Doesn't work in RI
- Deprecated in the RI, no need to implement since we have XmlIsSetNullPolicy?
- mgrebac: "Correct - deprecated, unused, we shall be able to remove it safely at this point actually."