PaulI did an initial implementation (see attachment). When I use this in TextFileDataSource, the test case I submitted on SYNAPSE-216 passes. Obviously it requires some more testing and I will also add some more comments to the code. I will submit a complete patch later.
Andreas
WrappedTextNodeStreamReader.java
Description: Binary data
On 28 Dec 2007, at 12:24, Paul Fremantle wrote:
Andreas I agree this is a pretty simple solution... I like it. Let me take a proper look later today when I get some time. PaulOn Dec 28, 2007 10:23 AM, Andreas Veithen <[EMAIL PROTECTED]> wrote:On 28 Dec 2007, at 10:16, Paul Fremantle wrote:The purpose of TextFileDataSource is actually to implement a text node(+ <text> wrapper element) that is backed by a temporary file rather than a String/char[] object, thereby avoiding to load the entire fileinto memory. Maybe we should consider another solution that avoids the problems described above. The idea would be to use a custom implementation of OMText (that again is backed by a temporary file). I think that if the custom implementation extends OMNodeImpl andimplements OMText, an instance can be added to the Axiom tree without problem, given that the Axiom code never casts OMText to OMTextImpl.An alternative (but less clean) solution would be to extend OMTextImpl.I agree these would work, but I'm not sure why this would be better than fixing up the DataSource model. The DataSource approach was designed to solve the problem of creating new forms of data-backed OMNodes. If it isn't working well enough we should raise this issue with the axiom dev team.The main argument in favor of the custom OMText solution was simplicity. There is however another solution that is a bit more complicated but that strictly adheres to the OMDataSource model. The idea is as follows. What TextFileDataSource does is to construct anInputStream that represents the concatenation <text> + text + </ text>.It then uses this input stream to build an XMLStreamReader. Theproblem comes from the fact that "text" is plain text, not XML text. Aquick fix could be to wrap the text in a CDATA section (i.e. <text><! [CDATA[ + text + ]]></text>), but this doesn't solve the character encoding problem. A better solution is then to implement a custom XMLStreamReader that synthesizes the following sequence of events: * START_DOCUMENT * START_ELEMENT * (CHARACTERS)*n * END_ELEMENT * END_DOCUMENT Since the output of XMLStreamReader for the CHARACTER events is purecharacter data, we don't need to care about XML entities and characterencoding at that level. To summarize, the solution would be to replace the custom InputStream implementation by a custom XMLStreamReader implementation. This XMLStreamReader implementation would have more or less the same complexity as the existing InputStream implementation. Regards, Andreas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]-- Paul Fremantle Co-Founder and VP of Technical Sales, WSO2 OASIS WS-RX TC Co-chair blog: http://pzf.fremantle.org [EMAIL PROTECTED] "Oxygenating the Web Service Platform", www.wso2.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
