[
https://issues.apache.org/jira/browse/CXF-1269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549181
]
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: https://issues.apache.org/jira/browse/CXF-1269
> 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.
