...

XSLT

...

Feature

...

Table of Contents

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

When should I use the Transformation Feature and when the XSLT Feature?

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

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

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

If you should apply non-trivial transformationtransformations, not supported by Transformation Feature - it is a use case for the XSLT Feature. Here you can write any custom XSL Transformation and apply it to inbound and/or outbound messages.
As far as the Xalan XSLT engine is actually not completely stream oriented, the XSLT Feature breaks streaming. However it uses the high-performance DTM (Document Table Model) instead of the 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).

...

It is necessary to configure the location of the 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 the XSLT path is not specified, no transformation will be done.

Configuring the XSLT Feature from

...

Spring/

...

Blueprint

The feature can be configured from the code in spring or blueprint 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);

...

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 XLSTInInterceptorXSLTInInterceptor/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.

...

The XSLT interceptors support the following message contents:

...