[
https://issues.apache.org/jira/browse/AXIOM-381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Veithen resolved AXIOM-381.
-----------------------------------
Resolution: Fixed
> DataHandlerExt#deleteWhenReadOnce() doesn't work as specified
> -------------------------------------------------------------
>
> Key: AXIOM-381
> URL: https://issues.apache.org/jira/browse/AXIOM-381
> Project: Axiom
> Issue Type: Bug
> Affects Versions: 1.2.9
> Reporter: Andreas Veithen
> Assignee: Andreas Veithen
> Priority: Minor
> Fix For: 1.2.13
>
>
> The Javadoc of DataHandlerExt#deleteWhenReadOnce() specifies the behavior of
> the method as follows:
> "This method will give users an option to trigger a delete on temporary
> attachment file when DataHandler associated with the attachment is read once.
> [...] This method gives options to user to trigger a delete on attachment
> files when they read the dataHandler once."
> This suggests that the deletion of the temporary file is triggered after the
> stream returned by DataHandler#getInputStream() has been consumed. The code
> in DataHandlerExtImpl is also designed such that the method can be called
> before (in which case the file would be deleted after accessing the data) or
> after accessing the data (in which case the file would be deleted
> immediately). However, in practice the implementation doesn't work like that.
> deleteWhenReadOnce() will actually always result in a call to
> purgeDataSource() and delete the file immediately. The explanation is as
> follows:
> - The access counter is kept in FileAccessor and it is incremented every time
> getDataHandler is called on the FileAccessor.
> - The DataHandlerExtImpl instance is created by FileAccessor#getDataHandler.
> This implies that for a given DataHandlerExtImpl object, the access counter
> in the corresponding FileAccessor is always non zero.
> - DataHandlerExtImpl#deleteWhenReadOnce() checks the access counter of the
> FileAccessor and if it is greater than zero, calls purgeDataSource(). This
> will always occur because at this point the access count can't be zero.
> The only exception would be for DataHandlerExtImpl instances created directly
> (i.e. not using FileAccessor#getDataHandler). Axiom internally always uses
> FileAccessor#getDataHandler and never creates a DataHandlerExtImpl directly.
> It is also unlikely that any application code creates a DataHandlerExtImpl
> directly, because the code in DataHandlerExtImpl is very tightly coupled to
> FileAccessor, LifecycleManager and CachedFileDataSource.
> It should also be noted that the code in question, which was added by
> AXIOM-269, has zero unit test coverage.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org
