axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Veithen <andreas.veit...@gmail.com>
Subject Re: MTOM broken?
Date Tue, 04 Jan 2011 21:13:17 GMT
Here is the complete explanation as I understand it:

1. The change was submitted with AXIS2-4712. The description of that
JIRA is correct, but the patch is incomplete. It was supposed to move
the call to setContentType into the if block, but the patch only
contained the part that adds the call into the if block and misses the
part that should remove the original call.

2. The fact that this code never caused troubles before is probably
due to the issue described with r823960. In earlier versions of Axiom,
the code generating the MTOM payload contained a call to
OutputStream#flush(). This meant that at the time setContentType is
called, the HTTP headers have already been written, so that
setContentType has no effect.

This means two things:
* Your change is correct and it matches the original intention of AXIS2-4712.
* Since the Axiom version has been upgraded on the 1.5 branch as well,
it is likely that MTOM is also broken in recent 1.5.x versions. Since
this is a severe issue, I will merge the fixes over to the 1.5 branch.

Thanks,

Andreas

On Tue, Jan 4, 2011 at 18:52, Afkham Azeez <afkham@gmail.com> wrote:
> Exactly! When you run the unit tests using SimpleAxisServer, the AxisServlet
> does not get hit.
> Azeez
>
> On Tue, Jan 4, 2011 at 11:05 PM, Andreas Veithen <andreas.veithen@gmail.com>
> wrote:
>>
>> Now I understand why this issue is not detected by any unit test (all
>> unit test use SimpleHttpServer). This piece of code was introduced by
>> Rich in r944074. What is strange is that the commit comment says that
>> it is supposed to remove the hardcoded text/xml, but the actual change
>> adds it. Maybe this was just a mistake in applying a patch (reverse
>> patch instead of normal patch)
>>
>> Andreas
>>
>> On Tue, Jan 4, 2011 at 18:19, Afkham Azeez <afkham@gmail.com> wrote:
>> > After some debugging, I found that the root cause for this is the code
>> > in
>> > lines 162-164 in AxisServlet. This code overrides the content-type set
>> > by
>> > the MessageFormatters. So, the serialized response message on the wire
>> > is
>> > invalid when enableMTOM is true on the server side. Here is the culprit
>> > code
>> > in AxisServlet.
>> > response.setContentType("text/xml; charset="
>> >                         + msgContext
>> >
>> >  .getProperty(Constants.Configuration.CHARACTER_SET_ENCODING));
>> > For example, here is one of the responses I received:
>> >
>> > HTTP/1.1 200 OK
>> > Server: Apache-Coyote/1.1
>> > Content-Type: text/xml;charset=UTF-8
>> > Transfer-Encoding: chunked
>> > Content-Encoding: gzip
>> > Vary: Accept-Encoding
>> > Date: Tue, 04 Jan 2011 15:19:52 GMT
>> > --MIMEBoundary_54171ca790b7b96d69703973e02d7a486e1fb748ceefd6fb
>> > Content-Type: application/xop+xml; charset=UTF-8; type="text/xml"
>> > Content-Transfer-Encoding: binary
>> > Content-ID:
>> > <0.44171ca790b7b96d69703973e02d7a486e1fb748ceefd6fb@apache.org>
>> > <?xml version='1.0' encoding='UTF-8'?><soapenv:Envelope
>> >
>> > xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Body><ns:additionResponse
>> >
>> > xmlns:ns="http://charitha.org"><ns:return>244</ns:return></ns:additionResponse></soapenv:Body></soapenv:Envelope>
>> > --MIMEBoundary_54171ca790b7b96d69703973e02d7a486e1fb748ceefd6fb--
>> > The correct response will have the Content-Type set to something similar
>> > to
>> > the following:
>> > Content-Type: multipart/related;
>> >
>> > boundary="MIMEBoundary_826ad2cd3c9f9139ddc2e9428b810eb4137fd90930f13ff8";
>> > type="application/xop+xml";
>> > start="<0.926ad2cd3c9f9139ddc2e9428b810eb4137fd90930f13ff8@apache.org>";
>> > start-info="text/xml"
>> > Azeez
>> > On Tue, Jan 4, 2011 at 7:26 PM, Afkham Azeez <afkham@gmail.com> wrote:
>> >>
>> >> Is MTOM working properly in the current Axis2 trunk?
>> >> We have some services with the enableMTOM parameter set to true and
>> >> when
>> >> we invoke those services using stubs generated using WSDL2Java, we get
>> >> this
>> >> error on the client side. Basically, the client cannot process the
>> >> response
>> >> it received.
>> >> com.ctc.wstx.exc.WstxUnexpectedCharException: Unexpected character '-'
>> >> (code 45) in prolog; expected '<'
>> >>  at [row,col {unknown-source}]: [1,1]
>> >> at
>> >>
>> >> com.ctc.wstx.sr.StreamScanner.throwUnexpectedChar(StreamScanner.java:648)
>> >> at
>> >>
>> >> com.ctc.wstx.sr.BasicStreamReader.nextFromProlog(BasicStreamReader.java:2047)
>> >> at com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1069)
>> >> at
>> >>
>> >> org.apache.axiom.util.stax.wrapper.XMLStreamReaderWrapper.next(XMLStreamReaderWrapper.java:225)
>> >> at
>> >>
>> >> org.apache.axiom.util.stax.dialect.DisallowDoctypeDeclStreamReaderWrapper.next(DisallowDoctypeDeclStreamReaderWrapper.java:34)
>> >> at
>> >>
>> >> org.apache.axiom.util.stax.wrapper.XMLStreamReaderWrapper.next(XMLStreamReaderWrapper.java:225)
>> >> at
>> >>
>> >> org.apache.axiom.om.impl.builder.StAXOMBuilder.parserNext(StAXOMBuilder.java:681)
>> >> at
>> >>
>> >> org.apache.axiom.om.impl.builder.StAXOMBuilder.next(StAXOMBuilder.java:214)
>> >> at
>> >>
>> >> org.apache.axiom.soap.impl.builder.StAXSOAPModelBuilder.getSOAPEnvelope(StAXSOAPModelBuilder.java:204)
>> >> at
>> >>
>> >> org.apache.axiom.soap.impl.builder.StAXSOAPModelBuilder.<init>(StAXSOAPModelBuilder.java:154)
>> >> at
>> >>
>> >> org.apache.axiom.soap.impl.builder.StAXSOAPModelBuilder.<init>(StAXSOAPModelBuilder.java:140)
>> >> at
>> >>
>> >> org.apache.axis2.builder.SOAPBuilder.processDocument(SOAPBuilder.java:67)
>> >> at
>> >>
>> >> org.apache.axis2.transport.TransportUtils.createDocumentElement(TransportUtils.java:179)
>> >> at
>> >>
>> >> org.apache.axis2.transport.TransportUtils.createSOAPMessage(TransportUtils.java:145)
>> >> at
>> >>
>> >> org.apache.axis2.transport.TransportUtils.createSOAPMessage(TransportUtils.java:108)
>> >> at
>> >>
>> >> org.apache.axis2.transport.TransportUtils.createSOAPMessage(TransportUtils.java:67)
>> >> at
>> >>
>> >> org.apache.axis2.description.OutInAxisOperationClient.handleResponse(OutInAxisOperation.java:354)
>> >> at
>> >>
>> >> org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:421)
>> >> at
>> >>
>> >> org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:229)
>> >> at
>> >>
>> >> org.apache.axis2.client.OperationClient.execute(OperationClient.java:165)
>> >>
>> >> If enableMTOM is set to false either in the service or the relevant
>> >> operation, the invocation returns successfully.
>> >> These services & clients were working fine earlier.
>> >> Any idea what could have gone wrong?
>> >> Thanks
>> >> Azeez
>> >>
>> >
>> >
>> >
>> > --
>> > Afkham Azeez
>> > Senior Software Architect & Senior Manager; WSO2, Inc.; http://wso2.com,
>> >
>> > Member; Apache Software Foundation; http://www.apache.org/
>> > email: azeez@wso2.com cell: +94 77 3320919
>> > blog: http://blog.afkham.org
>> > twitter: http://twitter.com/afkham_azeez
>> > linked-in: http://lk.linkedin.com/in/afkhamazeez
>> >
>> > Lean . Enterprise . Middleware
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>
>
>
> --
> Afkham Azeez
> Senior Software Architect & Senior Manager; WSO2, Inc.; http://wso2.com,
>
> Member; Apache Software Foundation; http://www.apache.org/
> email: azeez@wso2.com cell: +94 77 3320919
> blog: http://blog.afkham.org
> twitter: http://twitter.com/afkham_azeez
> linked-in: http://lk.linkedin.com/in/afkhamazeez
>
> Lean . Enterprise . Middleware
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org


Mime
View raw message