synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Asankha C. Perera" <>
Subject Re: Resolving SYNAPSE-218
Date Sun, 09 Mar 2008 14:17:26 GMT
> 1) Since OMSourcedElementImpl extends OMElement, a call to 
> serializeAndConsume should normally write out the entire element, i.e. 
> start tag, content (encoded as XML) and end tag. This is of course not 
> what is indented here. The code only works as expected because 
> TextFileDataSource doesn't respect the OMDataSource contract (which is 
> what SYNAPSE-218 is all about).
> 2) The instruction os.write(firstChild.getText().getBytes()) will 
> encode the content of the element using the default platform encoding, 
> which is not always what is expected. Note that for the output of an 
> XSL transformation, the content of the element is produced by the 
> following instruction in XSLTMediator#performXSLT:
> handleNonXMLResult(baosForTarget.toString(), traceOrDebugOn, traceOn)
> While considered separately this is also incorrect (since 
> ByteArrayOutputStream#toString uses the default platform encoding, 
> while the encoding of the stream depends on the stylesheet), in most 
> cases the net result is indeed that the response file will have the 
> encoding specified in the stylesheet. However this only works if the 
> combined transformation ByteArrayOutputStream#toString -> 
> String#getBytes is equivalent to the identity transformation. This is 
> not the case if the default platform encoding is e.g. UTF-8.
> The solution for the first problem is actually surprisingly simple. 
> The correct behavior can be achieved by replacing the code by the 
> following instructions:
> OMNode node = firstChild.getFirstOMChild();
> while (node != null) {
>     if (node instanceof OMText) {
>         os.write(((OMText)node).getText().getBytes());
>     }
>     node = node.getNextOMSibling();
> }
> I checked that for an OMSourcesElementImpl node backed by a 
> TextFileDataSource object, getFirstOMChild and getNextOMSibling will 
> read a single chunk of text from the WrappedTextNodeStreamReader 
> constructed by TextFileDataSource. Therefore the replacement code will 
> handle large temporary files with the same efficiency as the original 
> code.
I am to blame for the original code :-) But your suggestion looks cool 
so +1 to go ahead..
> An obviously solution for the second problem is to allow the 
> configuration of the output encoding in the VFS transport (and to 
> correct XSLTMediator!). However there might be cases where the user 
> wants to specify the output encoding in the XSLT stylesheet. This 
> could be achieved by allowing XSLTMediator to be configured to use a 
> binary wrapper instead of a text wrapper for text output. In this case 
> Synapse would strictly preserve the output of the XSL transformation.
Can we allow the user to provide the encoding optionally? If its not 
provided, we will default to binary..


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message