[
https://issues.apache.org/jira/browse/MIME4J-72?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12638270#action_12638270
]
Markus Wiederkehr commented on MIME4J-72:
-----------------------------------------
Please reconsider what the original issue was. A message allocates temporary
files that are not deleted until the jvm terminates. That was the situation
with 0.4 and the reason I filed this trouble ticket.
So clearly it should be possible to free these resources once a Message object
is no longer needed. This should be a fundamental part of the API and in my
opinion it should be _simple to use_.
message.accept(new DisposingEntityVisitor()) is not very straight forward but
message.dispose() is.
Of course you could add a convenience method in Message and do the visitor
thing there. That would essentially make message disposable again.
But then I would like to have the same feature in BodyPart because if I remove
a BodyPart from it's parent Entity ultimately I want to get rid of it. So
BodyPart should be disposable.
Please don't get me wrong. I like the visitor idea. Many cool things could be
done with a visitor such as copying and manipulating a message. But disposing a
message and all its resources is such a fundamental thing that I don't see that
you really need a visitor for it.
But speaking of manipulating a message. Would not a visitor that recognized
Message and Multipart be a bit more powerful?
Something like this:
public interface BodyVisitor {
void visitMessage(Message message);
void visitMultipart(Multipart multipart);
void visitBody(Body body);
}
public abstract class AbstractBodyVisitor implements BodyVisitor {
public void visitMessage(Message message) {
beginMessage(message);
Body body = message.getBody();
if (body != null) {
body.accept(this);
}
endMessage(message);
}
public void visitMultipart(Multipart multipart) {
beginMultipart(multipart);
List bodyParts = multipart.getBodyParts();
for (Iterator it = bodyParts.iterator(); it.hasNext();) {
Body body = ((BodyPart) it.next()).getBody();
if (body != null) {
body.accept(this);
}
}
endMultipart(multipart);
}
protected void beginMessage(Message message) {
}
protected void endMessage(Message message) {
}
protected void beginMultipart(Multipart multipart) {
}
protected void endMultipart(Multipart multipart) {
}
}
Note that the traversal happens in the abstract implementation instead of in
Message and Multipart.
> 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
>
>
> 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]
