[ 
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]

Reply via email to