XSLT Feature

The CXF XSLT Feature is alternative to CXF Transformation Feature providing flexible way to do the dynamic transformations of XML messages.
XSLT Feature applies custom XSL transformations to inbound and/or outbound messages.

When should I use Transformation Feature and when XSLT Feature?

If only trivial transformations must be done, it is recommended to use lightweight and fast Transformation Feature. It covers the most use cases as:

• dropping the namespace of the outbound messages;
• qualifying the incoming message;
• changing namespaces;
• appending or dropping elements;
• converting attributes to elements.

Transformation Feature is completely stream oriented and work fast especially for large messages.

If you should apply non-trivial transformation, not supported by Transformation Feature - it is use case for XSLT Feature. Here you can write any custom XSL Transformation and apply it to inbound and/or outbound messages.
As far as Xalan XSLT engine is actually not completely stream oriented, XSLT Feature breaks streaming. However it uses high-performance DTM (Document Table Model) instead complete DOM model.
Performance can be improved in the future by using further versions of Xalan or other XSLT engines (like Saxon or STX oriented Joost).

Spring configuration

It is necessary to configure XSLT script for inbound or/and outbound transformation. Example:

    <bean id="xsltFeature" class="org.apache.cxf.feature.transform.XSLTFeature">
        <property name="inXSLTPath" value="requestTransformation.xsl" />
        <property name="outXSLTPath" value="responseTransformation.xsl" />
    </bean>

The XSLT scripts should be available from the classpath. If XSLT path is not specified, no transformation will be done.

Configuring the XSLT Feature from the Spring/Bluepring

The feature can be configured from the code for JAX-WS or JAX-RS clients and endpoints. Example:

	<jaxws:client id="customerService" serviceName="customer:CustomerServiceService"
		endpointName="customer:CustomerServiceEndpoint" address="http://localhost:9091/CustomerServicePort"
		serviceClass="com.example.customerservice.CustomerService">
		<jaxws:features>
			<ref bean="xsltFeature" />
		</jaxws:features>
	</jaxws:client>

	<jaxws:endpoint xmlns:customer="http://customerservice.example.com/"
		id="CustomerServiceHTTP" address="http://localhost:9090/CustomerServicePort"
		serviceName="customer:CustomerServiceService" endpointName="customer:CustomerServiceEndpoint"
		implementor="com.example.customerservice.server.CustomerServiceImpl">
		<jaxws:features>
                      <ref bean="xsltFeature" />
		</jaxws:features>
	</jaxws:endpoint>

Configuring the XSLT interceptors in code

Here is how a JAX-WS client can be configured:

  CustomerServiceService service = new CustomerServiceService();
  CustomerService customerService = service.getCustomerServicePort();
  Client client = ClientProxy.getClient(customerService);
  XSLTOutInterceptor outInterceptor = new XSLTOutInterceptor(Phase.PRE_STREAM, StaxOutInterceptor.class, null,
                                                                   XSLT_REQUEST_PATH);
  client.getOutInterceptors().add(outInterceptor);

XSLT interceptors and phases

By default XSLT interceptors run on POST_STREAM and PRE_STREAM phases.
In some cases it may be needed to change the phase, for example, the in transformation has to be applied after the encrypted payload has been decrypted and its signature checked.
For such transformations to succeed XLSTInInterceptor/XSLTOutInterceptor will need to be created with a constructor accepting a 'phase' String parameter.
Additionally you can specify before and after interceptors for this phase as further constructor parameters.

Supported message contents

The XSLT interceptors support following message contents:

• InputStream/OutputStream;
• Reader/Writer;
• XMLStreamReader/XMLStreamWriter.

Therefore the interceptors can be used on different phases. XSLT Interceptors were tested with JMS Transport uses JMS Text messages (produces Reader/Writer message contents).