james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Markus Wiederkehr (JIRA)" <server-...@james.apache.org>
Subject [jira] Commented: (MIME4J-72) Provide a means to dispose a Message
Date Thu, 09 Oct 2008 12:14:44 GMT

    [ 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()

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) {
        Body body = message.getBody();
        if (body != null) {

    public void visitMultipart(Multipart multipart) {
        List bodyParts = multipart.getBodyParts();
        for (Iterator it = bodyParts.iterator(); it.hasNext();) {
            Body body = ((BodyPart) it.next()).getBody();
            if (body != null) {

    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,
> 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
> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message