Child pages
  • Proposed EmailService additions
Skip to end of metadata
Go to start of metadata


Sakai's EmailService is easy to use, but limited in features. Developers of Sakai tools just need to call EmailService.send() with minimal options such as the recipient's email address, subject, and message. But it does not accommodate attachments, instead offering the file picker as a workaround.

The Mailtool (in version 2.3) refactored EmailService for attachment capability, and duplicated much of the EmailService code in to create a "local" version of EmailService handling under a method called processSendEmail() (see the link to below).

As a point of comparison, the Message Center has two main functions for communicating among site members: discussion forums and private messaging. Private messaging of MC is almost the same as Mailtool - sending messages to site members. It also has own mailbox while Mailtool uses the Email Archive tool as its mailbox. MC's private messaging can send attachments using the File picker (redirect to Resource and then send the link, not the file itself).

But many of our use cases involve attachments relevant for the message, yet not files that the sender cares to upload to resources. Redirecting them to additional screens for attachment handling has also been a usability complaint - they want something quicker and easier.

The current proposed enhancements to EmailService would essentially add handling for both attachments and MIME messages.

Proposed Enhancements to EmailService

The following introduces a new send method that uses a container object rather than passing each parameter as an argument. The current methods of EmailService will stay for backwards compatibility.

void send(EmailMessage emailMessage);

The full EmailMessage object is attached. The propeties are shown below.

public class EmailMessage
	// who this message is from
	private EmailAddress from;

	// addressee for replies
	private EmailAddress replyTo;

	// recipients of message
	private List<EmailAddress> recipients;

	// subject of message
	private String subject;

	// body content of message
	private String body;

	// attachments to consider for message
	private List<File> attachments;

	// arbitrary headers for message
	private HashMap<String, String> headers;

	// mime type of message
	private String mimeType;

	// character set of text in message
	private String charset;

	// whether to embed attachments to message or persist to resource store
	private boolean embedAttachments;

	// where to put files in the resource store.  Only used if embedAttachments == true.
	private String embedLocation;

By using classes that are not directly dependent on javax.mail, using the EmailService to send messages doesn't also require another build dependency. This will allow for easier mail implementation upgrades.

Old (current) send():

Mailtool's processSendEmail():

(it's attachment-enabled. <sakai:inputFileUpload> takes care of file upload. Mailtool just gets the location(absolute file path) of uploaded file in Sakai server)

  • No labels


  1. Hi Clay,

    I'm not sure if this is the right place for this comment, but will MailTool be made to respect the email test mode property ( I was testing MailTool on a local machine and got a little befuddled when the message took quite a long time (around a minute?) to say it was sent. When it finally gave the sent screen, there was no trace of the email. I'm guessing that MailTool hit its SMTP timeout and gave up.

    1. Can you make a JIRA about this, Mike? The mailtool is currently listed as a "component" of Sakai in Jira, so you can identify it that way, and then assign it to Soo Il.

  2. Mailtool does not use Sakai EmailService. Therefore, at this time, does not affect any log.

    Not sure why SMTP timeout occur. If it's JIRA-ed, I will investigate more.

  3. And I suppose that's why this page is a good place to talk about it (smile) This page is all about the project to extend the EmailService far enough that the mailtool can use it.