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
