Details
-
Bug
-
Status: Resolved
-
Minor
-
Resolution: Fixed
-
1.2.9
-
None
-
None
Description
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.