[
https://issues.apache.org/jira/browse/AXIOM-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13092300#comment-13092300
]
Hudson commented on AXIOM-381:
------------------------------
Integrated in ws-axiom-trunk #514 (See
[https://builds.apache.org/job/ws-axiom-trunk/514/])
AXIOM-381: Deprecated DataHandlerExt#deleteWhenReadOnce(). The existing
purgeDataSource() or the new readOnce() method can be used to get the desired
behavior.
veithen :
Files :
*
/webservices/commons/trunk/modules/axiom/modules/axiom-api/src/main/java/org/apache/axiom/attachments/lifecycle/DataHandlerExt.java
> 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: [email protected]
For additional commands, e-mail: [email protected]
