You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by jim ma <ma...@gmail.com> on 2010/01/04 08:41:48 UTC
SAAJ for xop element
Hi all ,
When set the jaxws handler in client side to check if CXF 2.2.5 can
get the XOP element(xop:include element) content(encoded message) from
the SAAJ model . It looks like the SAAJIn/OutInterceptor does not
parse and inline the encoded request message in the "dataHandler"
element :
The expected document in SAAJ is:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<ns2:echoDataHandler xmlns:ns2="http://org.jboss.ws/xop/doclit">
<dataHandler>Q2xpZW50IGRhdGE=</dataHandler>
</ns2:echoDataHandler>
</soap:Body>
</soap:Envelope>
The actual document in the SAAJ :
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body><ns2:echoDataHandlerResponse
xmlns:ns2="http://org.jboss.ws/xop/doclit">
<dataHandler><xop:Include
xmlns:xop="http://www.w3.org/2004/08/xop/include"
href="cid:ca461d40-25f5-4a67-b3db-6b2b258563ee-4@http%3A%2F%2Fcxf.apache.org%2F"/>
</dataHandler>
</ns2:echoDataHandlerResponse>
</soap:Body></soap:Envelope>
This is the handler code to check if the xop:include element has been
replaced to actual encoded message :
public boolean handleMessage(SOAPMessageContext ctx) {
Object b = ctx.get(MessageContext.MESSAGE_OUTBOUND_PROPERTY);
boolean outbound = (Boolean) b;
if (!outbound) {
try {
SOAPMessage soapMsg = ctx.getMessage();
SOAPEnvelope soapEnv = soapMsg.getSOAPPart().getEnvelope();
SOAPBody body = soapEnv.getBody();
boolean found = scanNodes(body.getChildNodes());
if (found)
throw new IllegalStateException("Failed to get the actual encoded
message ");
} catch (SOAPException ex) {
throw new WebServiceException(ex);
}
return true;
}
return true;
}
Below is the soap request message on wire . Metro seems can handle
this as I expected. So Is this an issue in CXF ? Or this has been
defined in the SAAJ spc ?
---------------------Request message-----------------------
POST /jaxws-samples-xop-doclit/bare HTTP/1.1
Content-Type: multipart/related; type="application/xop+xml";
boundary="uuid:642da05d-d9b9-417c-a1aa-29a8c01ad9f3";
start="<ro...@cxf.apache.org>"; start-info="text/xml"
SOAPAction: ""
Accept: */*
User-Agent: Apache CXF 2.2.5
Cache-Control: no-cache
Pragma: no-cache
Host: 127.0.0.1:9999
Connection: keep-alive
Content-Length: 807
--uuid:642da05d-d9b9-417c-a1aa-29a8c01ad9f3
Content-Type: application/xop+xml; charset=UTF-8; type="text/xml";
Content-Transfer-Encoding: binary
Content-ID: <ro...@cxf.apache.org>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><ns2:echoDataHandler
xmlns:ns2="http://org.jboss.ws/xop/doclit"><dataHandler><xop:Include
xmlns:xop="http://www.w3.org/2004/08/xop/include"
href="cid:ce273950-41cd-4447-b3b7-296c06672f7a-1@http%3A%2F%2Fcxf.apache.org%2F"/></dataHandler></ns2:echoDataHandler></soap:Body></soap:Envelope>
--uuid:642da05d-d9b9-417c-a1aa-29a8c01ad9f3
Content-Type: text/plain
Content-Transfer-Encoding: binary
Content-ID: <ce273950-41cd-4447-b3b7-296c06672f7a-1@http://cxf.apache.org/>
Client Data
Thanks
Jim
Re: SAAJ for xop element
Posted by Daniel Kulp <dk...@apache.org>.
Jim,
I chatted with the Thomas Diesler about this a long time ago. Some of the
comments are at:
https://issues.apache.org/jira/browse/CXF-1261
Basically, there isn't anything in the specs that say the saaj model, when the
handler is called, should have it in one form or the other. For CXF, we've
gone the "higher performance and lower memory footprint" route of not inlining
the data.
To give an example: lets say you have a 100MB MTOM attachment. With CXF,
the SAAJ message would just have the xop element and the 100MB attachment
would either remain streamed or buffered into a file on disk.
If we inlined it, we would need to read in the 100MB stream, base64 encode it
(so it would expand to 125MB) and put it into the saaj model as a String
(which would double the size to 250MB due to 16bit chars). Thus, the memory
requirement is SIGNIFICANTLY more. Also, we then would feed that SAAJ model
(wrapper it with an XMLStreamReader) into JAXB which would then have to re-
decode the base64 data. With the current approach, JAXB just reads the
bytes directly (or passes the steaming DataHandler/DataSource directly).
So, with inlining, you would have SIGNIFICANTLY higher memory requirements
along with significantly higher processor utilization (for the base64 encode
and decode). Since the spec doesn't require it, we don't do it.
We could probably add an option to the SAAJ interceptors to inline things if
we really needed it. I'd keep it off by default though for the above
reasons.
Dan
On Mon January 4 2010 2:41:48 am jim ma wrote:
> Hi all ,
>
> When set the jaxws handler in client side to check if CXF 2.2.5 can
> get the XOP element(xop:include element) content(encoded message) from
> the SAAJ model . It looks like the SAAJIn/OutInterceptor does not
> parse and inline the encoded request message in the "dataHandler"
> element :
>
> The expected document in SAAJ is:
>
> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
> <soap:Body>
> <ns2:echoDataHandler xmlns:ns2="http://org.jboss.ws/xop/doclit">
> <dataHandler>Q2xpZW50IGRhdGE=</dataHandler>
> </ns2:echoDataHandler>
> </soap:Body>
> </soap:Envelope>
>
> The actual document in the SAAJ :
>
> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
> <soap:Body><ns2:echoDataHandlerResponse
> xmlns:ns2="http://org.jboss.ws/xop/doclit">
> <dataHandler><xop:Include
> xmlns:xop="http://www.w3.org/2004/08/xop/include"
> href="cid:ca461d40-25f5-4a67-b3db-6b2b258563ee-4@http%3A%2F%2Fcxf.apache.or
> g%2F"/> </dataHandler>
> </ns2:echoDataHandlerResponse>
> </soap:Body></soap:Envelope>
>
> This is the handler code to check if the xop:include element has been
> replaced to actual encoded message :
>
> public boolean handleMessage(SOAPMessageContext ctx) {
> Object b = ctx.get(MessageContext.MESSAGE_OUTBOUND_PROPERTY);
> boolean outbound = (Boolean) b;
> if (!outbound) {
> try {
> SOAPMessage soapMsg = ctx.getMessage();
> SOAPEnvelope soapEnv =
soapMsg.getSOAPPart().getEnvelope();
> SOAPBody body = soapEnv.getBody();
> boolean found = scanNodes(body.getChildNodes());
>
> if (found)
> throw new IllegalStateException("Failed to get the
actual encoded
> message ");
>
> } catch (SOAPException ex) {
> throw new WebServiceException(ex);
> }
>
> return true;
> }
> return true;
>
> }
>
> Below is the soap request message on wire . Metro seems can handle
> this as I expected. So Is this an issue in CXF ? Or this has been
> defined in the SAAJ spc ?
>
> ---------------------Request message-----------------------
> POST /jaxws-samples-xop-doclit/bare HTTP/1.1
> Content-Type: multipart/related; type="application/xop+xml";
> boundary="uuid:642da05d-d9b9-417c-a1aa-29a8c01ad9f3";
> start="<ro...@cxf.apache.org>"; start-info="text/xml"
> SOAPAction: ""
> Accept: */*
> User-Agent: Apache CXF 2.2.5
> Cache-Control: no-cache
> Pragma: no-cache
> Host: 127.0.0.1:9999
> Connection: keep-alive
> Content-Length: 807
> --uuid:642da05d-d9b9-417c-a1aa-29a8c01ad9f3
> Content-Type: application/xop+xml; charset=UTF-8; type="text/xml";
> Content-Transfer-Encoding: binary
> Content-ID: <ro...@cxf.apache.org>
> <soap:Envelope
> xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><ns2:ech
> oDataHandler
> xmlns:ns2="http://org.jboss.ws/xop/doclit"><dataHandler><xop:Include
> xmlns:xop="http://www.w3.org/2004/08/xop/include"
> href="cid:ce273950-41cd-4447-b3b7-296c06672f7a-1@http%3A%2F%2Fcxf.apache.or
> g%2F"/></dataHandler></ns2:echoDataHandler></soap:Body></soap:Envelope>
> --uuid:642da05d-d9b9-417c-a1aa-29a8c01ad9f3
> Content-Type: text/plain
> Content-Transfer-Encoding: binary
> Content-ID: <ce273950-41cd-4447-b3b7-296c06672f7a-1@http://cxf.apache.org/>
> Client Data
>
>
> Thanks
>
> Jim
>
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog