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 20:08:24 GMT
     [ http://nagoya.apache.org/jira/browse/AXIS-1654?page=history ]

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

    Attachment: AttachmentPartTest.java

My previous unit test was only half there - the patch code didn't take into account that detachAttachmentFile
had been called (the file would still go). Please find attached new unit test.

Suggested code fix - add a boolean to track call to detachAttachmentFile - as per snippets
below. This code passes the modified unit test.

    /**
     * Indicates that file has been detached and should not to be deleted.
     */
    private boolean fileDetached = false;

    public void detachAttachmentFile() {
        fileDetached = true;       
        attachmentFile=null;
    }

    public synchronized void dispose() 
    {
       if (fileDetached == false)
       {
    	    javax.activation.DataSource ds = datahandler.getDataSource();
          if (attachmentFile != null || ds instanceof ManagedMemoryDataSource) 
          {
             ((ManagedMemoryDataSource) ds).delete(); // and delete the file
             if(attachmentFile != null)
             {
                // set the filename to null to stop repeated use
                setAttachmentFile(null);
             }
          } 
          else 
          {
              File f = new File(attachmentFile);
              // no need to check for existence here.
              f.delete();
          }
       } // if
        // 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;
    }


> 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, 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