2011/12/19 Steve Brewin <[email protected]>: > I created this as a proposal as I expected some disagreement along the way > :) > > In my view changing from the Mailet container taking care of managing > resources to placing the responsibility on the Mailet developer is a > retrograde step that is unnecessary to achieve our objectives.
Once we add the methods to create a Mail to the MailetContext then the MailetContext (e.g: the container) will be able to keep track of resources and will be able to dispose them after service method returned. So, there is no need to make "dispose" method public. > It also exposes the possibility for dispose() to be invoked inappropriately > against Mail instances passed into the Mailet Container. I guess the previous sentence makes this answer not useful, but anyway I want to add that james is vulnerable to mailets and in no way try to protect from malicious mailets (dispose would just be one more thing in thousands). > We would be destabilising much to achieve very little. What is so wrong with > the proposed closure style solution I made earlier? IMO it is unnecessary right now (but I maybe wrong, of course), as we just need some more code in the container and some javadoc on the new methods, explaining that mail instances returned by the 2 methods cannot be referenced after service method return because the server will dispose them. We could even automatically track if a mailet creates a new mail object without actually sending/storing it. Stefano
