Metro swaRef and invalid MIME
I searched the forum but didn't find a similar thread.
I have an issue where I have a service with a method like
public javax.activation.DataHandler download ( ... )
The WSDL for the service looks fine e.g.
<xs:sequence><xs:element name="return" type="swaRef:swaRef" minOccurs="0"/></xs:sequence>
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
Keep-Alive: timeout=5, max=100
Content-Type: multipart/related; type="text/xml"; boundary="uuid:824407c2-b8dc-4a51-a4cc-32a8e651def6"
Content-Type: text/xml; charset=utf-8
... SOAP response here, looks OK ...
.. DataHandler payload here, looks OK ...
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.