Manage Attachments in Memory
File attachments can be a real drain on system performance. They can be arbitrarily big, and most methods for handling them involve writing them out to disk. This requires access to a directory on the server and can impose all sorts of performance penalties.
JavaMail, oddly, doesn’t support nontext MIME parts
based on objects in memory. JAF
DataHandler
objects can be retrieved only from a file or URL. This means that
even if you’ve generated the attachment in memory,
you still have to write it out to disk and then attach the ondisk
file to your email. The exception, as you’ve seen,
is when you already have a DataHandler object,
such as when you receive an incoming SOAP message via JAXM.
Example 10-7 shows how to get around this limitation
by subclassing the
MimeBodyPart
object. The standard
MimeBodyPart
implementation includes a protected field,
contents, that contains the raw content of the
MIME part. The JavaMail API also includes a utility class,
MimeUtility
,
that can encode content streams in a variety of ways, including with
the base64 and the older UUEncode standards. You can use these two
features to create your own MIME encoding system, bypassing JAF
altogether.
The
StreamBasedMimeBodyPart
class has a constructor that accepts an
InputStream, a content type, and a filename. The filename is associated with the file attachment so that the recipient can open it easily. Because this is a simple example, the constructor contains all the logic, ...