...

• Pure introspection
• JAXB-ish annotations
• Mapping files files

Aegis' pure introspection behavior is much like that of JAXB. Given a class or a method, it will derive a sensible mapping to WSDL and XML Schema. It will map packages to namespaces, classes to types, properties to elements, and methods to operations.

...

There is also a procedure for adding custom mappings beyond the capabilties of these basic methods. There are several 'custom' mapping supplied, for items ranging from Gregorian Calendar dates to MTOM attachments.

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.

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.

One important aspect of the DefaultTypeMapping registry which turns up in other aspects of Aegis is that it is really multiple registries: one per service target namespace, plus extras for soap encodings. There is some very confusing terminology in the code: the name encodingStyleURI is used in the DefaultTypeMappingRegistry for the key to the map of the registries, when in fact what ends up in that key can be either a Soap encoding style URI (e.g. http://schemas.xmlsoap.org/soap/encoding/^{Image Added}) or the namespace URI of a service (as initialized by AegisDatabinding.getNamespaceURI()).

(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 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.