XSLT Feature
The CXF XSLT Feature is an alternative to the CXF Transformation Feature, providing a flexible way to dynamically transform XML messages.
The XSLT Feature applies custom XSL transformations to inbound and/or outbound messages.
If only trivial transformations must be done, it is recommended to use the lightweight and fast Transformation Feature. It covers 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 works fast especially for large messages.
If you should apply non-trivial transformations, 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 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).
Spring configuration
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 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);
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 XSLTInInterceptor/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 the 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).