A common question that appears on the forums is something like: "How do I map an object to an XML element with attributes and text in JAXB?". The answer is to use JAXB's @XmlValue annotation. In this post I'll demonstrate how this annotation can be leveraged.
Everyone knows that by default JAXB uses the no-argument constructor when instantiating objects. Readers of this blog are also familiar with using XmlAdapters to build objects. In this post I'll cover how the use of factory classes and methods can be configured through the @XmlType annotation.
JAXB offers a lot of flexibility when interacting with your object model. One area is configuring the use of fields or properties to access the data in your domain objects. This is specified as an XmlAccessType (PUBLIC_MEMBER, PROPERTY, FIELD, or NONE) via the @XmlAccessorType annotation. In this post we'll examine what these options really mean.
On behalf of the MOXy JAXB committers (great job by all), I am very proud to announce that EclipseLink 2.3 has been released and is available for download. In this post I will summarize what is new in the MOXy component:
Recently I have discussed support for extensible models in EclipseLink JAXB (MOXy) 2.3. The metadata for the extensions is supplied via MOXy's mapping document. In this post I will demonstrate how to leverage MOXy's support for multiple mapping documents to keep your metadata organized.
In this example we will leverage EclipseLink JAXB (MOXy)'s concepts of externalized metadata (represented as a MetadataSource), and extensible models. The MetadataSource will be used to define the metadata for the extensions. In EclipseLink 2.3 we have introduced the ability for a JAXBContext to be "refreshed". This means that without stopping the application we can supply metadata about new extensions.
EclipseLink JAXB (MOXy) provides an XML mapping document as an alternative to using annotations. This mapping document can be provided in many different forms: resource path, URL, File, Source, etc. If however you store your metadata in some sort of repository this flexibility might not be enough. This is why in EclipseLink 2.3 we have introduced a new mechanism to support this use case.
In a multi-tenant architecture a single application runs on a server, serving multiple client organizations (tenants). Good multi-tenant applications allow per-tenant customizations. When these customizations are made to data, it can be difficult for the binding layer to handle them. In this post I'll demonstrate how to leverage EclipseLink JAXB (MOXy)'s support for extensible models to easily handle this use case.
JAXB is designed to work with domain models that have real fields/properties. In EclipseLink 2.3, MOXy introduces the concept of virtual properties. Virtual properties are defined by the MOXy metadata file, and provide a way to extend a class without modifying the source. In this post I'll describe what virtual properties are, and in upcoming posts I'll cover how they can be leveraged:
In previous articles I have covered how to map inheritance relationships in JAXB and EclipseLink MOXy. In this example I will describe how to remove an inheritance relationship in JAXB by leveraging @XmlTransient at the type level.