cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Kulp (JIRA)" <>
Subject [jira] Commented: (CXF-1269) Using contentType = "application/octet-stream" on returned Datahandler/DataSource causes an InputStream to be left open
Date Thu, 06 Dec 2007 20:47:43 GMT


Daniel Kulp commented on CXF-1269:

Looking through the code, I THINK this might be caused in JAXBAttachmentMarshaller.addMtomAttachment(....)

if ("application/octet-stream".equals(handler.getContentType())) {
            try {
                Object o = handler.getContent();
                if (o instanceof String 
                    && ((String)o).length() < THRESHOLD) {
                    return null;
                } else if (o instanceof byte[]
                            && ((byte[])o).length < THRESHOLD) {
                    return null;
            } catch (IOException e1) {
                //ignore, just do the normal attachment thing

Most likely, instead of calling handler.getContent(), we should call handler.getDataSource()
and check if it's a URLDataSource or FileDataSource and do something a bit smarter in those
cases.   My gut feeling is that the call to getContent is returning a FileInputStream that
is holding onto it.

I'd appreciate it if someone would mess around with that and see if that's the issue.   If
so, send a patch!

> Using contentType = "application/octet-stream" on returned Datahandler/DataSource causes
an InputStream to be left open
> -----------------------------------------------------------------------------------------------------------------------
>                 Key: CXF-1269
>                 URL:
>             Project: CXF
>          Issue Type: Bug
>    Affects Versions: 2.0.2
>         Environment: Running CXF in Jetty using bare bones cxf-service.xml config 
>            Reporter: Zack Jones
> Our service returns a Datasource whos getContentType() method returns "application/octect-stream".
Method is named getMessage() and returns a DataHandler and a messageId in a wrapped type.
> Our service also contains a method to remove the file source associated with this Datasource
by passing the messageId in the request.
> A client side test fails because the message can't  be deleted, presumably b/c an InputStream
to the file is left open. 
> This only recently became an issue as before we were returning type "text/xml", which
worked as expected. It was desirable to change the type as our WSDL has the xmime:expectedContentTypes="application/octet-stream"
attribute on the base64Binary type so we can use DataHandlers on the client side.
> Unfortunately we switched back to using text/xml.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message