Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] OutOfMemoryError

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Wolfgang Hoschek <wolfgang.hoschek AT mac.com>
  • To: Wolfgang Hoschek <wolfgang.hoschek AT mac.com>
  • Cc: Elliotte Harold <elharo AT metalab.unc.edu>, xom-interest AT lists.ibiblio.org, m AT lhaza.com
  • Subject: Re: [XOM-interest] OutOfMemoryError
  • Date: Fri, 20 Jan 2006 14:52:44 -0800


On Jan 20, 2006, at 2:31 PM, Wolfgang Hoschek wrote:


On Jan 20, 2006, at 2:05 PM, Elliotte Harold wrote:

Wolfgang Hoschek wrote:

Bottom line: I don't think XOM can or should do something about
this problem.

Possibly. I am considering whether I could add an extra protected
method to NodeFactory that would be called once for each
invocation of characters() by SAX and which would enable such
buffering. Currently XOM has to buffer in XOMHandler anyway. It
might be possible to move this into NodeFactory.

I guess there's no SAX property that would force the underlying
parser to limit character() chunks to <= X bytes. So no guarantee can
be given that an OOM error can be avoided. Even if there's no error
with parser X today, it might be different with a different parser,
or with a different version.

Plus, what about very large base64 comment nodes?

I still believe that such an unusual use case is best dealt with by a
custom SAX content handler, rather than at the XOM level. Too much
additional complexity for too little additional value.


I should add that if the MIME/multipart route doesn't apply, then STAX/Woodstox may well be a more natural fit for this scenario than SAX. In particular via the STAX method XMLStreamReader.getTextCharacters(int sourceStart, char[] target, int targetStart, int length).

My local Nux devel version already has production quality STAX support for XOM. In a nutshell it contains:

1) a facility to write XOM documents to a STAX XMLStreamWriter (StreamingSerializerFactory)
2) a subclass of nu.xom.Builder that has the same behaviour as the XOM Builder, except that it runs over STAX (StaxUtil.getBuilder())
3) a class that allows to build XOM documents, fragments, nodes, etc, from STAX, with or without a NodeFactory (StaxParser)
4) a class that makes a XOM tree appear as a STAX XMLStreamReader (StaxUtil.asXMLStreamReader(ParentNode))

Option 3) most closely applies to the large base64 case, enabling a client to call XMLStreamReader.getTextCharacters(...) directly without any XOM interference.

Wolfgang.





Archive powered by MHonArc 2.6.24.

Top of Page