[jira] Updated: (AXIS-1654) Small attachments creating attachment files that are not cleaned up

["Ashutosh Shahi (JIRA)" <ax...@ws.apache.org>]

     [ http://nagoya.apache.org/jira/browse/AXIS-1654?page=history ]

Ashutosh Shahi updated AXIS-1654:
---------------------------------

    Attachment: patch_1654.txt

Sean,
     Am posting a patch for the above issue. But i don't have a test case to verify it works. Can u test it at your end or post your wsdl and client code so that i can test the changes?
Ashutosh

> Small attachments creating attachment files that are not cleaned up
> -------------------------------------------------------------------
>
>          Key: AXIS-1654
>          URL: http://nagoya.apache.org/jira/browse/AXIS-1654
>      Project: Axis
>         Type: Bug
>     Versions: beta-3
>     Reporter: Sean Barnett
>     Priority: Minor
>  Attachments: patch_1654.txt
>
> The class AttachmentPart wraps ManagedMemoryDataSource. The latter determines whether to store attachments to disk or in memory based upon attachment size, and AttachmentPart notes this decision through the member variable "attachmentFile"
>     public AttachmentPart(javax.activation.DataHandler dh) {
>         setMimeHeader(HTTPConstants.HEADER_CONTENT_ID,
>                 SessionUtils.generateSessionId());
>         datahandler = dh;
>         if(dh != null) {
>             setMimeHeader(HTTPConstants.HEADER_CONTENT_TYPE, dh.getContentType());
>         javax.activation.DataSource ds = dh.getDataSource();
>         if (ds instanceof ManagedMemoryDataSource) {
>     	extractFilename((ManagedMemoryDataSource)ds); //and get the filename if appropriate
>         }
>         }
>     }
> If the programmer gets the data source from underneath the attachment part by calling "getDataHandler().getDataSource()", and then calls getName() on that data source the ManagedMemoryDataSource forces storage to disk by internally calling flushToDisk(). 
>     public java.lang.String getName() {
>         String ret = null;
>         try {
>             flushToDisk();
>             if (diskCacheFile != null) {
>                 ret = diskCacheFile.getAbsolutePath();
>             }
>         } catch (Exception e) {
>             diskCacheFile = null;
>         }
>         return ret;
>     }
> AttachmentPart does not know that a disk file has been created underneath it, and when dispose() is called fails to call delete on the ManagedMemoryDataSource ...
>     public synchronized void dispose() {
>         if (attachmentFile != null) {
>             javax.activation.DataSource ds = datahandler.getDataSource();
>             if (ds instanceof ManagedMemoryDataSource) {
>                 ((ManagedMemoryDataSource) ds).delete(); //and delete the file
>             } else {
>                 File f = new File(attachmentFile);
>                 //no need to check for existence here.
>                 f.delete();
>             }
>             //set the filename to null to stop repeated use
>             setAttachmentFile(null);
>         }
>         //clean up the datahandler, as it will have been
>         //invalidated if it was bound to a file; if it wasnt
>         //we get to release memory anyway
>         datahandler = null;
>     }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira