You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Amichai Rothman (JIRA)" <se...@james.apache.org> on 2019/03/25 10:20:00 UTC

[jira] [Created] (JAMES-2700) No way for a Mailet to create a Mail

Amichai Rothman created JAMES-2700:
--------------------------------------

             Summary: No way for a Mailet to create a Mail
                 Key: JAMES-2700
                 URL: https://issues.apache.org/jira/browse/JAMES-2700
             Project: James Server
          Issue Type: Bug
          Components: Matchers/Mailets (bundled)
    Affects Versions: 3.4.0
            Reporter: Amichai Rothman


Implementations of Mailets often need to create new Mail messages, as evidenced by the several MailetContext.sendMail methods that accept a Mail instance to send. However, the API does not provide for a mechanism to create a new Mail nor set all of the fields of an existing Mail (only some have setters).

This means that a Mailet implementation must use a container-specific implementation to create such a mail (e.g. it must create a new org.apache.james.server.core.MailImpl).

However this dependency seems to defeat the purpose of having an independent Mailet API, where Mailets and Matchers can be used in different containers or applications, and makes them all coupled to the full James server alone. Alternatively, in order to be independent, a Mailet must provide its own full implementation of a Mail, and I'm not even sure if that would work in James. For comparison, imagine if a Servlet was required to create a Tomcat-specific Response object in order to function... that would fail the whole ecosystem of servlets.

I think a better approach would be to provide a factory (whether an independent factory interface or simply another method in the MailetContext) that creates a new Mail instance that can then be sent via the sendMail methods. This may also require adding some setters to the Mail interface so that the mail contents can be fully specified, or alternatively creating a new subclass interface such as WritableMail that adds those modifying methods, so that the read-only view of the object can still be enforced when necessary.

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org