[
https://issues.apache.org/jira/browse/MIME4J-72?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12638462#action_12638462
]
Markus Wiederkehr commented on MIME4J-72:
-----------------------------------------
Oleg, here are a few more thoughts, please bear with me..
dispose method: unless you decide to keep the entire message in memory you will
_always_ have the need to free the backing resources when the message is no
longer needed. Regardless of what backing mechanism you want to use. Therefore
the typical use case looks like this:
Message message = acquireMessage();
try {
doSomethingFancy(message);
}
finally {
disposeMessage(message);
}
Clearly message.dispose() is more convenient than message.accept(new
DisposingEntityVisitor()).
So this is not something exotic. You dispose of a message for the same reasons
you close an I/O stream. It has to be an inherent part of the API.
Regarding the visitor, Oleg's vs Markus'.. Please consider a message like this
one:
message
multipart #1
text part #1
multipart #2
binary part #1
binary part #2
binary part #3
I believe that your visitor cannot be used to copy the structure of this
message. It gets notified of the entities and bodies in the order they appear.
Therefore it is impossible to determine if binary part #3 belongs to multipart
#1 or multipart #2.
Besides, what good is a visitor if I have to do all the instance-of checks by
myself. If I wanted to do instance-of I would not need a visitor in the first
place.
After all a visitor is only a crutch for languages that don't have a multiple
dispatch mechanism. So the visitor should inform you on the concrete leaf
classes as good as possible.
> 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: entityvisitor.patch, mime4j-disposable.patch,
> mime4j-dispose-finalize.patch, mime4j-dispose-no-clutter.patch,
> mime4j-dispose-visitor.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]
