samedi 2 février 2013

JAXB/XJC: Select properties included in equals, hashcode and toString methods

When you generate source code from your WSDL/XSD using XJC, you may also want to generate equals, hashcode and/or toString methods. This is done by passing extra arguments to XJC. For example, when using the cxf-codegen-plugin with Maven, these arguments are passed as follows:


By default, the generated methods use all the properties in the generated classes. Often, only a part of the properties compose the business key, and uniqueness should be determined based only on these properties. This concerns the equals and hashcode methods. For the toString method, one may want part of the properties to be displayed by the method.

In order to select the properties to be used by these methods, custom bindings have to be set. These bindings may be provided directly in the XML schema or externally using a separate file.

Here, I will show how this can be done using a separate file but the same applies when the first way is used.

First, the bindings file must be created. There is no required extension for this file but since it consists of an XML document, the .xml extension is appropriated. Assume we have the following complex type declared in the XML schema:

<xs:schema targetnamespace="target-namespace" xmlns:tns="target-namespace" xmlns:xs="">
   <xs:complextype name="PersonType">
         <xs:element name="idNumber" type="xs:string"/>
         <xs:element name="lastName" type="xs:string"/>
         <xs:element name="firstName" type="xs:string"/>

In the generated class PersonType, we only want the idNumber property to be used by the equals and hashcode methods. Assume we also want only the lastName and firstName properties to be displayed by the toString method. Therefore, we need to specify this as bindings as follows:

<jxb:bindings node="/xs:schema" schemalocation="XmlSchema.xsd" version="2.1" xmlns:equals="" xmlns:hashcode="" xmlns:jxb="" xmlns:tostring="" xmlns:xs="">
        <jxb:bindings node="//xs:complexType[@name='PersonType']/xs:sequence/xs:element[@name='idNumber']">
        <jxb:bindings multiple="true" node="//xs:complexType[@name='PersonType']/xs:sequence/xs:element[position()&gt;1]">

The path of the XML entity on which the custom JAXB binding applies is indicated in the node attribute as an XPath expression. Note that these paths are relative to the node identified by the XPath expression in the node attribute present in the top <jxb:bindings> element (here it is /xs:schema). 

It is also important to note that the order of definition of the elements in the complex type is important since the position() method is used to select all the elements but the first one (i.e. idNumber).

Also, when the XPath expression present in the node attribute targets more than one node, the multiple attribute must be set to true.

Configuring TLS on the client with CXF

When your web service is secured using TLS (this is generally done at the web container level, e.g. Tomcat), your client has to be configured to work properly.

Here, I briefly describe how to configure a CXF client to work with TLS.

When TLS is used, the server must be authenticated by the client. Optionnaly, the client may also be authenticated by the server.

This configuration is done through the HTTPConduit instance associated with your client. The HTTPConduit is obtained as follows:

Client client = ClientProxy.getClient(proxy);

HTTPConduit httpConduit = (HTTPConduit) client.getConduit();

Then, you need to create a TLSClientParameters instance that will wrap the TLS configuration. There are two ways to provision the TLSClientParameters with TLS configuration:
  • using an SSLSocketFactory instance
  • or, by provisioning the TLS configuration using the multiple properties of the TLSClientParameters instance

Here, I will describe the second way.

First, for the client to authenticate the server, instances of TrustManager should be provided. One possibility is to use a TrustManagerFactory initialized using a truststore. A truststore is a container for the security data (e.g. a file that contains certificates of trusted entities). In Java, it is represented by an instance of the KeyStore class. Assume you have a truststore that contains the trusted certificate of the server, you can initialize a TrustManagerFactory as follows:

// A specific algorithm may be provided or the default algorithm may 

// be obtained using TrustManagerFactory.getDefaultAlgorithm() 

TrustManagerFactory trustManagerFactory = TrustManagerFactory.getInstance(algorithm);


When your TrustManagerFactory is initialized, you can obtain the TrustManager instances as follows:

TrustManager[] trustManagers = trustManagerFactory.getTrustManagers();

Then, you provision your TLSClientParameters instance as follows:
TLSClientParameters tlsClientParams = new TLSClientParameters();


Finally, you provision the HTTPConduit with the TLSClientParameters:

If you are using mutual authentication (i.e. the client is also authenticated by the server), the client authentication part must also be configured. For this purpose, a class "symmetric" to TrustManager is used: KeyManager. As for TrustManager instances, a KeyManagerFactory is initialized using a keystore, also represented by a KeyStore instance.

// A specific algorithm may be provided or the default algorithm may 

// be obtained using KeyManagerFactory.getDefaultAlgorithm() 

KeyManagerFactory keyManagerFactory = KeyManagerFactory.getInstance(algorithm);

keyManagerFactory.init(keystore, password); // The password is required since sensible data is accessed

As for TrustManager, KeyManager instances are obtained and provisioned to the TLSClientParameters instances:

KeyManager[] keyManagers = keyManagerFactory.getKeyManagers();