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 Fri, 10 Oct 2008 18:29:44 GMT

    [ https://issues.apache.org/jira/browse/MIME4J-72?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12638623#action_12638623
] 

Markus Wiederkehr commented on MIME4J-72:
-----------------------------------------

@Oleg

By now it seems to be clear that we won't be able to reach a consensus. So for now this will
be my last comment on the issue. It's your project after all and you can do with it what you
want. I also don't want to stand in the way of your upcoming 0.5 release.

But let me comment on a few of your statements:

> Not all Message instances are generated by reading data from an I/O stream. Why _all_
of them should be disposable?

Because it is convenient. The dispose method in Message I proposed is nothing more that a
convenience method that uses your disposing visitor. You don't have to call dispose if you
can be sure that your message resides entirely in memory.

If such a small convenience method is such a bit thorn in your eye, have you considered replacing
Message.writeTo() with a visitor implementation? That would only be consequent since you don't
always need writeTo() either.

> Your implementation currently does seem to correctly handle embedded messages because
it does not check the type of individual Parts in a Multipart entities.

My implementation correctly handles embedded messages because of a sophisticated feature called
polymorphism, you might want to check on it.

> Added BodyWalker classes intended to traverse the hierarchy of Body objects contained
in a message and to invoke a BodyVisitor interface on visited Body instances

So now I have to write "new BodyWalker(new DisposingBodyVisitor()).walk(message)" to get rid
of my message? This is getting better and better..

> (Markus) If I wanted to do instance-of I would not need a visitor in the first place

Your BodyWalker is exactly what I meant by that. It uses instance-of checks instead of simply
utilizing polymorphism. So it is not even a true visitor in the meaning of the classical design
pattern.

Even the Java example in the Wikipedia article on the visitor pattern (http://en.wikipedia.org/wiki/Visitor_pattern)
works exactly as my version does. Object traversal is done in the visitor implementation (PrintVisitor.visitCar())
by invoking _accept_ (not visit) on the child element to visit next.

Markus

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


Mime
View raw message