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. Paul On 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 file > >> into 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 and > >> implements 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 an > InputStream that represents the concatenation <text> + text + </text>. > It then uses this input stream to build an XMLStreamReader. The > problem comes from the fact that "text" is plain text, not XML text. A > quick 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 pure > character data, we don't need to care about XML entities and character > encoding 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]
