This Page is a Work In Progress
Summary (Why use Aegis?)
The purpose of Aegis is to allow you to control how your classes and methods are serialized in the web service environment without requiring intrusive modifications to your source code. If you are willing to modify your source code to include annotations, you should probably use JAXB. JAXB code can move to other web service toolkits. Aegis is a private feature of CXF. Aegis allows you to specify the same sorts of things that JAXB allows you to specify. The difference is where and how you specify them. In Aegis, for a class (or interface) named 'SomeObjectOfMine', you place a file names SomeObjectOfMine.aegis.xml (called a mapping file) in the classpath in the same project. Aegis reads the XML file for instructions.
CXF includes a total of three databindings: Aegis, JAXB, and Source. As soon as the present author figures our what Source is for, he will add some commentary comparing it to Aegis.
Basic Process
Think of Aegis as processing your classes and methods in three levels:
...
There is also a procedure for adding custom mappings beyond the capabilities of these basic methods.
Basic Configuration and Options
Aegis has some global configuration, and then some per-service configuration. The global configuration is organized in the AegisDatabinding object.
The Configuration object
The AegisDatabinding accepts a Configuration object. The configuration objects sets defaults for type mapping. The properties should be self-explanatory, as they correspond to the usual option attributes of XML schema types and elements. Note that 'extensibleElements' means adding xs:any to the WSDL Complex Type Definition.
The namespaceMap
The AegisDatabinding accepts a Map<String, String> to control the assignment of namespace prefixes. Most application have no interest in the assignment of prefixes. The semantics of XML are concerned with the actual namespace URI or URL strings, not the prefixes. However, there are some cases (such as very basic clients coded in simple languages) in which is it desirable to set up controlled, immutable, prefix mappings. The Map keys are namespaces, and the values are prefixes. Needless to say, both sides of the map have to be unique.
The TypeMappingRegistry
Much of the operation of Aegis is coordinated by the TypeMappingRegistry. There is only one implementation of this interface: the DefaultTypeMappingRegistry. As the name suggests, it maintains a unique mapping from classes (both data beans and service interfaces and implementations) to CXF type descriptions. Unless you are undertaking a very serious complex customization, you should not be contemplating replacing or extending this class. (As of this writing, in fact, it is final. That is likely to change, but it is still not a good idea.
...
(More information to come as the author figures out what all this is about).
Per-service Configuration
Each CXF service implements Map<String, Object> to allow you to specify additional configuration information. Aegis looks for the following keys:
- OVERRIDES_TYPES_KEY: a List<Class> of additional classes to map in the schema. This is most useful for allowing derived classes of declared Exceptions to be marshalled to the client.
- READ_XSI_TYPES_KEY: A string (false or true). When not "false", Aegis will respect xsi:type attributes. What is this good for?
- WRITE_XSI_TYPES_KEY: Whether to write xsi:type attributes.
Default Mapping Details
To begin with, the DefaultTypeMappingRegistry establishes a set of mapping for basic types. For services declared to operate with Soap 1.1, it sets up two sets of mappings.
Soap 1.1 SOAP mappings
Type | SOAP Mapping |
---|---|
boolean | Soap-encoded boolean |
Boolean | Soap-encoded boolean |
int | Soap-encoded int |
Integer | Soap-encoded int |
short | Soap-encoded int |
Short | Soap-encoded int |
double | Soap-encoded double |
Double | Soap-encoded double |
float | Soap-Encoded float |
Float | Soap-Encoded float |
long | Soap-encoded long |
Long | Soap-encoded long |
char | Soap-encoded char |
Character | Soap-encoded char |
String | Soap-encoded String |
java.sql.Date | Soap-encoded date-time |
java.util.Calendar | Soap-encoded date-time |
byte[] | soap-encoded Base64 |
BigDecimal | Soap-encoded Decimal |
BigInteger | Soap-encoded BigInteger |
Soap 1.1 XSD mappings
Type | XSD Mapping |
---|---|
boolean | XSD boolean |
Boolean | XSD boolean |
int | XSD int |
Integer | XSD int |
short | XSD int |
Short | XSD int |
double | XSD double |
Double | XSD double |
float | XSD float |
Float | XSD float |
long | XSD long |
Long | XSD long |
char | XSD char |
Character | XSD char |
String | XSD String |
java.sql.Date | XSD date-time |
java.sql.Time | XSD time |
java.util.Calendar | XSD date-time |
byte[] | XSD Base64 |
BigDecimal | XSD Decimal |
BigInteger | XSD Integer |
org.w3c.Document | XSD Any |
org.jdom.Document | XSD Any |
org.jdom.Element | XSD Any |
javax.xml.transform.source | XSD Any |
javax.xml.stream.XMLStreamReader | XSD Any |
Object | XSD Any |
javax.activation.DataSource | XSD Base64 via MTOM data source type (See org.apache.cxf.argis.type.mtom) |
javax.activation.DataHandler | XSD Base64 via MTOM data source type (See org.apache.cxf.argis.type.mtom) |
Services that Don't Use Soap 1.1
The type mappings for non-Soap-1.1 services start out with the same XSD types as the Soap-1.1 services
...
Type | Mapping |
---|---|
javax.xml.datatype.Duration | XSD Duration |
javax.xml.datatype.XMLGregorianCalendar | XSD Date |
javax.xml.datatype.XMLGregorianCalendar | XSD Time |
javax.xml.datatype.XMLGregorianCalendar | XSD gDay |
javax.xml.datatype.XMLGregorianCalendar | XSD gMonth |
javax.xml.datatype.XMLGregorianCalendar | XSD gMonthDay |
javax.xml.datatype.XMLGregorianCalendar | XSD gYear |
javax.xml.datatype.XMLGregorianCalendar | XSD gYearMonth |
javax.xml.datatype.XMLGregorianCalendar | XSD Date-Time |
Customizing Type Mapping
Each of the standard type mappings is a relationship between a Java class object and a subclass of org.apache.xxf.aegis.Type. If you want to add your own class-level mapping, you can implement your own subclasses of Type, and register them against your service URI (or an encoding style URI) in the type mapping registry. Reading the source of the standard objects is required here.
The Type Creators
The type mapping registry maintains a chain of TypeCreator objects. These objects do the work of creating mappings for Java types that are not pre-mapped via the standard types above or custom mappings that you install. The XMLTypeCreator handled mapping files. For historical reasons, the rest of the process is split between the Java5TypeCreator and the DefaultTypeCreator. Historically, XFire supported Java 1.4, so all the code that depended on Java 1.5 (both annotation processing and generic type processing) was quarantined in the Java5TypeCreator.
...