axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sean Barnett (JIRA)" <axis-...@ws.apache.org>
Subject [jira] Updated: (AXIS-1654) Small attachments creating attachment files that are not cleaned up
Date Wed, 10 Nov 2004 10:15:33 GMT
     [ http://nagoya.apache.org/jira/browse/AXIS-1654?page=history ]

Sean Barnett updated AXIS-1654:
-------------------------------

    Attachment: AttachmentPartTest.java

This is a quick junit test that fails without the patch, and works with the patch.

> 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: AttachmentPartTest.java, 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


Mime
View raw message