Details
-
Type:
Improvement
-
Status:
Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: None
-
Fix Version/s: None
-
Component/s: IO
-
Labels:None
Description
The currently implemented AbstractPullReader/Writer provides methods for getting/setting text of the current node. It would be great to set/get text in multiple step such as using XMLStreamReader#getTextCharacters()/XMLStreamWriter#writeCharacters().
Activity
No problem, i should have described my problem a little better. I'm using XStream in our project for marshalling/unmarshalling a XML. The XML file contains a large file as payload which size can be between 10KB-5MB. A major benefit of using PULL parser it doesn't consume a lot of memory for processing a large XML file (you know that
). I think the currently provided AbstractPullReader/Writer class is only an adapter for push parsing. I can't rely on the AbstractPullReader/Writer to optimize the processing of the xml file part in my own converter. Here is an example:
public class SwappingFileConverter implements Converter
{ public boolean canConvert(Class clazz); public void marshal(Object value, HierarchicalStreamWriter writer, MarshallingContext context); public Object unmarshal(HierarchicalStreamReader reader, UnmarshallingContext context); }The SwappingFileConverter#unmarshal() method should return a File object and write the xml file-part into a specified file. What can i do in the unmarshal() method? I can get the content of the current node using AbstractPullReader.getValue(). It reads the full content into the memory but i wouldn't be necessary. The AbstractPullReader/Writer should provide a method for reading/writing a part of the current node's content (sream based concept). I think this will be backward compatible i doesn't affect any module expect the pull readers/writers.
Denes Csepely
added a comment - No problem, i should have described my problem a little better. I'm using XStream in our project for marshalling/unmarshalling a XML. The XML file contains a large file as payload which size can be between 10KB-5MB. A major benefit of using PULL parser it doesn't consume a lot of memory for processing a large XML file (you know that ). I think the currently provided AbstractPullReader/Writer class is only an adapter for push parsing. I can't rely on the AbstractPullReader/Writer to optimize the processing of the xml file part in my own converter. Here is an example:
public class SwappingFileConverter implements Converter
{
public boolean canConvert(Class clazz);
public void marshal(Object value, HierarchicalStreamWriter writer,
MarshallingContext context);
public Object unmarshal(HierarchicalStreamReader reader,
UnmarshallingContext context);
}
The SwappingFileConverter#unmarshal() method should return a File object and write the xml file-part into a specified file. What can i do in the unmarshal() method? I can get the content of the current node using AbstractPullReader.getValue(). It reads the full content into the memory but i wouldn't be necessary. The AbstractPullReader/Writer should provide a method for reading/writing a part of the current node's content (sream based concept). I think this will be backward compatible i doesn't affect any module expect the pull readers/writers. OK, you mean, the reader should not only provide
String getValue()
but also as alternative
Reader readValue()
that can be used to optimize value access in a real stream based scenario? Makes sense (same applies to Writer).
Jörg Schaible
added a comment - OK, you mean, the reader should not only provide
String getValue()
but also as alternative
Reader readValue()
that can be used to optimize value access in a real stream based scenario? Makes sense (same applies to Writer). Yes, it is exactly what i mean.
Denes Csepely
added a comment - Yes, it is exactly what i mean. 
I am not sure what you suggest here, sorry. The StaxWriter already uses XMLStreamWriter.writeCharacters(). To use XMLStreamReader#getTextCharacters() in the StaxReader we would have to perform some major restructurings in the pull parser support. Concerning "multiple steps to read and write", well, I suppose this means a change of the HierarchicalStreamReader/Writer - but what for? This would have a major compatibility issue. So, unless you have a good use case and provide some real numbers for an increase in performance, nothing will happen.
Simply stating that you need some change and you know now it better is not enough. You might know it really better - but I cannot qualify.