[
https://issues.apache.org/jira/browse/MIME4J-72?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637850#action_12637850
]
Markus Wiederkehr commented on MIME4J-72:
-----------------------------------------
@Bernd:
dispose() should free any resources that cannot be reclaimed by the garbage
collector. This implies that dispose() essentially destroys the object and it
can no longer be used afterwards. So idempotency cannot be an issue here. It is
perfectly okay for an object to behave unpredictably once disposed. You would
not expect an InputStream to work as it did before once you have closed it,
would you?
The intention is to dispose an object and leave it to the garbage collector. If
you continue to use it your are doing something wrong.
As for the pollution of the framework, this is a valid point. But the disposed
flag is entirely optional and can be removed. I will provide a patch for that
shortly.
Your third concern was "all files failing deletion are visited (again (and
again))". I don't see where this happens. There is no dispose call inside a
finally block (the super.dispose() in TempFileBinaryBody only sets the parent
to null, there is no recursion, loop or anything).
Considering your proposal of a ResourceManager on TempFile*Body..
TempFileTextBody and TempFileBinaryBody aren't even public classes.. And the
use case is to simply dispose a message and free all temp files held by it or
its parts. With my approach you simply call message.dispose() and be done with
it. With your approach you would first have to traverse the message hierarchy
down to the TempFile*Bodys, obtain the ResouceManager and then free the
resources - seems like a lot of work to me.
> Provide a means to dispose a Message
> ------------------------------------
>
> Key: MIME4J-72
> URL: https://issues.apache.org/jira/browse/MIME4J-72
> Project: JAMES Mime4j
> Issue Type: Improvement
> Affects Versions: 0.5
> Reporter: Markus Wiederkehr
> Assignee: Robert Burrell Donkin
> Attachments: mime4j-disposable.patch, mime4j-dispose-finalize.patch,
> mime4j-dispose-no-clutter.patch
>
>
> Currently an org.apache.james.mime4j.message.Message uses temporary files to
> store text and binary attachments of the message. Unfortunately a Message
> cannot be disposed of explicitly. Even when it eventually gets garbage
> collected the temp files continue to exist until the VM exits.
> If the VM runs for a long time and a lot of e-mails get processed this can
> become a major problem.
> For this reason I think that class Entity and interface Body should both have
> a method to dispose of the object. Multipart should dispatch a dispose-call
> to its list of body parts. A BodyPart should dispose of its body and concrete
> Body implementation such as TempFileTextBody should ultimately invoke
> delete() on the backing TempFile.
> Last but not least SimpleTempStorage$SimpleTempFile should not silently
> ignore delete-calls.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
