Attachment cleanup revision #2

[Steve Loughran <st...@iseran.com>]

I've been thinking of a simpler way to do attachment cleanup, or at least
give services access to the paths of files (and let them do cleanup
themselves, or move the files away)


(a) AttachmentPart stores the path to the file, if the data was stored to a
file; has public accessors.

(b) ManagedMemoryDataSource adds an accessor to its filename

(c) the various inputstream methods hand off their ManagedMemoryDataSource
to AttachmentPart.addDatasourceFilename(ManagedMemoryDataSource source),
which stores the filename (so the polling for filename and adding is all in
one place)

(d) services can get the filename and either (1) work with the file, (2)
given the path, move it somewhere, (3) unset the AttachmentPart file path
property so as to prevent autocleanup

(e) the AttachmentPart adds a dispose() call to delete the file, if
filename!=null

(f) the classes finalizer calls dispose()

So we dont need a complex design for disposal patterns, yet we add access to
files, and the ability to move files or remove them from the list of files
to delete. And it keeps more of an OO design of each object looking after
itself, without having to know how it is used.

We can put this stuff in now (I'm running it; it lets me get at big files
without copying them), cleanup is kept to the scope of the objects that need
to know about them, and there is no need for any complex design.

So, what do people think? I think this approach would be a very way to meet
user needs.

-steve