Page History

...

For example, here is a Simple front-end service using Aegis as a data binding.

  <simple:server id="pojoservice" serviceClass="demo.hw.server.HelloWorld" 
  address="/hello_world">
  	<simple:serviceBean>
    		<bean class="demo.hw.server.HelloWorldImpl" />
  	</simple:serviceBean>
         <simple:dataBinding>
       <bean class="org.apache.cxf.aegis.databinding.AegisDatabinding" />
    </simple:dataBinding>
  </simple:server>
 </bean>

AegisDatabinding is the class that integrates Aegis into CXF as a databinding.

Note that AegisDatabinding beans, like all databinding beans, are not reusable. The example
above uses an anonymous nested bean for the databinding. If you make a first-class bean for
a databinding, be sure to use scope='prototype' if you are inclined to define more than one endpoint.

...

How about the reverse process: deserializing? (JAXB calls this unmarshalling.) In this case, by default, Aegis is presented with an XML element and asked to produce a Java object. Recall, however, that the Aegis maintains a mapping from Java types to XML Schema Types. By default, an XML instance document offers no information as to the type of a given element. How can Aegis determine the Java type? Outside of CXF, the application would have to tell Aegis the expected type for the root element of a document.

Or, as an alternative, Aegis can add xsi:type attributes to top-level elements when writing. It will always respect them when reading.

Inside CXF, however, Aegis gets the benefit of the Message and Part information for the service. The WSDL service configuration for a service gives enough information to associate an XML Schema type with each part. Once the front-end has determined the part, it can call Aegis with the QName for the schema type, and Aegis can look it up in the mapping.

Will it be in the mapping? Yes, inside CXF because Aegis precreates mappings for the types in the service's parts. Aegis cannot dynamically create or choose a Java class based on XML schema, so the type creators cannot start from XML. Thus, outside CXF you are responsible for ensuring that your top-level types are mapped.

Schema Validation

As of CXF 2.3, the Aegis databinding can leverage the Schema Validation capabilities built into the Woodstox 4.x Stax parser to validate incoming requests. To enable this, you must do the following:

1. Make sure you are using the Woodstox 4.x Stax parser and not a 3.x or other parser. By default, CXF 2.3 ships with an appropriate version of Woodstox.
2. If not using the CXF bundle jar, (example, if using maven), you'll need to add the cxf-wstx-msv-validation-2.3.0.jar to the classpath
3. If not using maven or similar to obtain the cxf-wstx-msv-validation jar, you'll also need to add the msv validation jars as CXF does not ship them by default. You will need:

   Code Block
   isorelax-20030108.jar msv-

   2.3.0.jar to the classpath

   core-2009.1.jar relaxngDatatype-20020414.jar xercesImpl-2.9.1.jar xml-resolver-1.2.jar xsdlib-2009.1.jar

4. If not using a default bus (such as configuring your own spring context), you'll need to add:

   Code Block
   xml xml
   <import resource="classpath:META-INF/cxf/cxf-extension-wstx-msv-validation.xml" />

   to load the validator utilities that Aegis will use.
5. Turn on schema validation like you would for JAXB by using the @SchemaValidation annotation or setting the "schema-validation-enabled" property on the endpoint to "true".

...

<mappings>
	   <mapping>
		      <method name="getUnannotatedStrings">
			         <return-type name="UnannotatedStringCollection" 
             componentType="java.lang.String"/>
		      </method>
        <method name="getValues">
         <parameter index="0" componentType="java.lang.String"/>
        </method>
	   </mapping>
</mappings>

Annotations

...