Skip to main content

Metro swaRef and invalid MIME

Please note these java.net forums are being decommissioned and use the new and improved forums at https://community.oracle.com/community/java.
1 reply [Last post]
adamspe
Offline
Joined: 2008-06-17

I searched the forum but didn't find a similar thread.

I have an issue where I have a service with a method like

...
@javax.xml.bind.annotation.XmlAttachmentRef()
public javax.activation.DataHandler download ( ... )

The WSDL for the service looks fine e.g.

<xs:complexType name="downloadResponse">
<xs:sequence><xs:element name="return" type="swaRef:swaRef" minOccurs="0"/></xs:sequence>
</xs:complexType>

In this case I'd expect a simple SOAP payload response with a return element referencing a MIME part containing the contents of the DataHandler. For the most part this is true but Metro seems to start an EXTRA MIME part (even though it knows up front there will be only one) with no data and never terminates the MIME stream. The client then fails to read the response complaining, properly, that the MIME is not terminated. I'm running into this while upgrading to Metro 2.1.1 from Metro 2.0 but I checked interactions using 2.0 and the same corrupt MIME was there (I just didn't realize it) but the client didn't complain and functioned despite the bad MIME.

To deal with very large responses the response data is chunked. An example of the bad MIME I'm getting is:

HTTP/1.1 200 OK
Date: Wed, 24 Aug 2011 19:00:07 GMT
Server: Apache/2.2.19 (Unix) mod_jk/1.2.31
X-Frame-Options: SAMEORIGIN
X-do-not-compress-this: 1
Vary: Accept-Encoding,User-Agent
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: multipart/related; type="text/xml"; boundary="uuid:824407c2-b8dc-4a51-a4cc-32a8e651def6"

1783
--uuid:824407c2-b8dc-4a51-a4cc-32a8e651def6
Content-Type: text/xml; charset=utf-8

... SOAP response here, looks OK ...

1ff8

--uuid:824407c2-b8dc-4a51-a4cc-32a8e651def6
Content-Id:<0ac869b0-e8f0-41be-a844-227b55fea5d2@example.jaxws.sun.com>
Content-Type: application/octet-stream
Content-Transfer-Encoding: binary

.. DataHandler payload here, looks OK ...

--uuid:824407c2-b8dc-4a51-a4cc-32a8e651def6
Content-Id:<0ac869b0-e8f0-41be-a844-227b55fea5d2@example.jaxws.sun.com>
Content-Type: application/octet-stream
Content-Transfer-Encodin
d
g: binary

0

I left in the chunk length lines, so don't be confused by the broken Content-Transfer-Encoding line which contains a chunk-length in the middle.

As you can see a new extra MIME part was started but never terminated. The end chunk marker is written and the MIME stream as a whole is corrupt. Again I see the same behavior with Metro 2.0 and 2.1.1 but on 2.1.1 the client side no complains appropriately about this bad MIME.

Has anyone run into this problem?

It really looks like a bug to me but I'm wondering if there's something I can do to work around it by changing either my server or client code.

Thanks.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
adamspe
Offline
Joined: 2008-06-17

Interestingly I re-wrote a much more simplified service that I could try to play around with to see if I could understand further with a download method like:

@XmlAttachmentRef()
@WebMethod(operationName="download",action="download")
public DataHandler download() throws Exception
{
final DataSource data = new DataSource ()
{
public String getContentType () { return "text/plain"; }
public InputStream getInputStream () throws IOException
{
return new ByteArrayInputStream ( "Hello World".getBytes() );
}
public String getName () { return "unknown"; }
public OutputStream getOutputStream () throws IOException { throw new UnsupportedOperationException (); }
};
return new DataHandler ( data );
}

The result is that Metro appends TWO MIME attachments containing the exact same data, even though there is only one reference! This somewhat makes sense as to why in the other case the MIME was broken if METRO is grounding out an IOException while trying to read the data from the DataHandler twice (as it can't be read twice). This looks even more like a bug to me.

In this case I see MIME like:

HTTP/1.1 200 OK
Date: Thu, 25 Aug 2011 13:36:22 GMT
Server: Apache/2.2.19 (Unix) mod_jk/1.2.31
X-Frame-Options: SAMEORIGIN
X-do-not-compress-this: 1
Vary: Accept-Encoding,User-Agent
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: multipart/related; type="text/xml"; boundary="uuid:33e52a4f-8129-4d63-936a-e689856de572"

174
--uuid:33e52a4f-8129-4d63-936a-e689856de572
Content-Type: text/xml; charset=utf-8

<?xml version='1.0' encoding='UTF-8'?><S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"><S:Body><ns2:downloadResponse xmlns:ns2="http://myorg.org/"><return>cid:5b56f960-e4f3-4820-9a48-d37a51494b86@example.jaxws.sun.com</return></ns2:downloadResponse></S:Body></S:Envelope>
1b3

--uuid:33e52a4f-8129-4d63-936a-e689856de572
Content-Id:<5b56f960-e4f3-4820-9a48-d37a51494b86@example.jaxws.sun.com>
Content-Type: text/plain
Content-Transfer-Encoding: binary

Hello World
--uuid:33e52a4f-8129-4d63-936a-e689856de572
Content-Id:<5b56f960-e4f3-4820-9a48-d37a51494b86@example.jaxws.sun.com>
Content-Type: text/plain
Content-Transfer-Encoding: binary

Hello World
--uuid:33e52a4f-8129-4d63-936a-e689856de572--
0