Hi Alex, The JsonRepresentation class is based on the official JSON library which is not using streams. Therefore, all the content is stored in memory. The current implementation derives from StringRepresentation and stores the JSON document as a serialized string. This is why you can get its size.
The DomRepresentation is similar in the sense that it is backed by a DOM document which is entirely stored in memory. Otherwise, it is not directly backed by a string, but by a DOM document instance instead. This is why we can't know its size in advance, for that we need to serialize it (which is what the getValue() method does). It seems to me that if you rely on a DOM representation, it means that the document should be small enough to be stored in memory and therefore a conversion to a string shouldn't be too expensive. Otherwise, I recommend using the SaxRepresentation which is fully stream-based. Finally, I'm wondering why knowning the size of your DomRepresentation in advance is so important? For example, the HTTP connectors can perfectly work with representations without knowing their size in advance as chunk encoding is supported. Best regards, Jerome > -----Message d'origine----- > De : news [mailto:[EMAIL PROTECTED] De la part de Alex Combs > Envoyé : vendredi 12 janvier 2007 22:32 > À : [email protected] > Objet : DomRepresentation Question > > (Currently using beta 20) > I am having a little bug with the DomRepresentation class. > When I instantiate > it with a Document {new DomRepresentation(MediaType.APPLICATION_XML, > myDocument)}, the DomRepresentation object does not store the > size of the > Document, which means that if I want to find it later I have > to convert it to a > String via getValue (a potentially slow process if the > Document is really big). > This is opposed to a JsonRepresentation which does store the > size by default. > Is there a plan to change/already implemented change for this > in a future > release (or heck, even in my current release, that I missed)? Thanks. > > -Alex
