[
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]