Hi Jason,
What you describe here is the transition from
| InputStream -> StAX -> JAXRPC Deserializer -> Java Object
|
Let me rehears what we've currently got:
Fragment incomming XML message (done in MessageFactory.createMessage()) and
create a flat SAAJ view
Document Style
--------------
SOAPEnvelope
SOAPHeader
SOAPHeaderElement (SOAPContentElement that holds a fragment)
SOAPBody
SOAPBodyElement (SOAPContentElement that holds a fragment)
RPC Style
---------
SOAPEnvelope
SOAPHeader
SOAPHeaderElement (SOAPContentElement that holds a fragment)
SOAPBody
SOAPBodyElement (RPC element)
SOAPElement (SOAPContentElement that holds a fragment)
SAAJ at this level is perfect to describe the structure of the SOAP message. It
starts to be less perfect the deeper you go down the tree
forcing the DOM view onto the user.
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.
In case we have handlers that modify the content we can alway go back to the
DOM view of the content using the corresponding serializer.
That should account for the majority of use cases and we don't hold a second
(xmlFragment) copy of the content.
As you point out correctly, we take the hit if the handler (or endpoint) is
stupid enough to require a DOM view of the content.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3859051#3859051
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3859051
-------------------------------------------------------
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
