"[EMAIL PROTECTED]" wrote : Hi Jason, | | The important bit is, to allow to go forth and back between the XML and Java Object representation at the SOAPContentElement level | using the JAXRPC serializer/deserializers. | | Whether to hold the XML representation as String or StAX events is an (important) implementation detail. | So how about this: | | MessageFactory.createMessage builds the SAAJ view as above with SOAPContentElement(s). | Upon END_ELEMENT the SOAPContentElement passes the event stream to the deserializer which constructs the java objects | and assigns it to the SOAPContentElement. If we don't have handlers the java object passes unmodified the endpoint. |
I had thought about adapting SAAJ in some way that would internally use StAX, but there are a couple of problems. 1) you have to scan through the whole message to build the outer SAAJ tree 2) Since the parser is forward only, you can't backtrack if you need to, which makes lazy loading difficult. Now its possible to cache the event objects for a block, which is more efficiant than a DOM tree, but it still requires you to effectivelly allocate a list of objects that is the size of the entire message. XML fragments have the same problem because you are still allocating a block of memory that is the size of the message. This prompted me to consider an alternative to using SAAJ, though I was not sure if there was a problem with this, since so much of the current design is built around SAAJ. I assumed that the reason for using it, was just to simplify passing elements to handlers. I was also working under the idea of trying to come up with a solution that allowed for parsing an indefinitely large message, with as minimal copies as possible. By not maintaining that SAAJ tree, we no longer have a need to hold on to any of the XML after we process it. So a SOAP message could be 1 TB for all we care, and we would only allocate a few K. This is just refering to space allocated for processing, I realize that if every single element in the SOAP message is actually deserialized into an object of equivalent size, the memory usage would be the same if not larger than the SOAP message. If however only a few elements are mapped to the message, the memory allocation would be quite small. So I guess the questions I have are: Is trying to optimze for a tiny memory footprint unnesessary or unrealistic? Are there other reasons to have an SAAJ tree that I didn't think of? -Jason View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3859084#3859084 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3859084 ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
