Hi Andrei, Mandy
Do you propose to have an interceptor which will be injected with a map
where the key is an operation name and the value is a template ref ?
That can work for all of CXF frontends. It is promising :-)
Perhaps another (or rather - the additional) option is to update the
existing XSLT interceptor to inject various request properties
(operation name, some header values, etc) into XSLT stylesheet.
At XSLT level this XSLT stylesheet becomes a master stylesheet which
will import per-operation specific stylesheets and use these injected
properties to decide where to delegate.
Thanks, Sergey
On 25/08/16 08:12, Andrei Shakirin wrote:
Hi Mandy,
I see.
Option for now is configure XLST interceptors dynamically from the other custom
interceptor recognizing the SOAPAction and configuring appropriate xslt
depending on service operation.
But basically I find this as a valid use case and support multiple XLSTs in
standard CXF interceptor IMO makes sense.
Default behaviour still will be the single xslt, but user becomes the option to
specify multiple xslts per operation (normally operations use different
schemas).
Please create a Jira, patch is welcome as well :)
@Sergey: do you see this in the same way?
Regards,
Andrei.
-----Original Message-----
From: Mandy Warren [mailto:[email protected]]
Sent: Donnerstag, 25. August 2016 00:03
To: [email protected]
Subject: Re: Changing message output
Hi Andrei,
Thanks for your reply! Good point! We just located the documentation for this
and looks good except we need to apply different xslt dependent on the
operation we call (the soap action) rather than having just a single xslt. We
can
however use your code for the basis of out solution (eg. the callback approach
etc). Should I raise a jira to suggest an enhancement to the existing solution?
We could send over our code once we have it working...
Many thanks
Mandy
Sent from a mobile device
On 22 Aug 2016, at 20:46, Andrei Shakirin <[email protected]> wrote:
Hi Mandy,
Nice to hear you again ;)
Don't the XSLT feature http://cxf.apache.org/docs/xslt-feature.html and
XSLTOut[In]Interceptor fit for your use case?
I guess they do almost the same as your code.
Regards,
Andrei.
-----Original Message-----
From: Mandy Warren [mailto:[email protected]]
Sent: Freitag, 19. August 2016 17:49
To: [email protected]
Subject: Changing message output
Hi,
We have a requirement to apply XSLT to incoming request XML and
outgoing response XML within CXF interceptors (to avoid changes to the
endpoint code).
We have used the following approach to modify the response XML and
would appreciate your comments to see whether this is an acceptable
approach or not. Note that the interceptor is registered at "pre-stream".
try (OutputStream outputStream =
message.getContent(OutputStream.class);
CachedOutputStream cachedStream = new CachedOutputStream();
InputStream resourceInputStream = resource.getInputStream()) {
message.setContent(OutputStream.class, cachedStream);
//Allow other interceptors execution so that finally output stream
will be populated with outgoing message.
message.getInterceptorChain().doIntercept(message);
//flush the stream so that we can see/extract the message.
cachedStream.flush();
//Get the xml message on which you want to apply transformation.
Source inputSource = getInputSource(message);
Source xslt = new StreamSource(resourceInputStream);
Transformer transformer = transformerFactory.newTransformer(xslt);
StreamResult streamResult = new StreamResult(outputStream);
transformer.transform(inputSource, streamResult);
outputStream.flush();
message.setContent(OutputStream.class, outputStream);
if(LOGGER.isDebugEnabled()){
//TODO response needs to be logged
LOGGER.debug("Transformed response: "+new
String(((CachedOutputStream)outputStream).getBytes()));
}
}
It seems to work but we're worried about any side effects.
Many thanks
Mandy
Sent from a mobile device
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
