[ http://issues.apache.org/jira/browse/JAMES-609?page=comments#action_12433706 ] Noel J. Bergman commented on JAMES-609: ---------------------------------------
I agree that it would be better to check in setMessage if this.message == message. None of these is a perfect solution, since the explicit dispose call reintroduces the problems that exist in other languages with explicit deallocation: how to know when it is safe to deallocate (and clean-up). What if someone were to call getMessage, put the old message object into a new Mail, and put a new message in the old Mail? But the least objectionable change for now is probably the check in setMessage. The logic for that one is clear: if we are setting the message to the one we already have, do nothing. > MailImpl.setMessage and possible NPE: regression from 2.2.0 and 2.3.0rc1 > ------------------------------------------------------------------------ > > Key: JAMES-609 > URL: http://issues.apache.org/jira/browse/JAMES-609 > Project: James > Issue Type: Bug > Components: James Core > Affects Versions: 2.3.0rc2 > Reporter: Stefano Bagnara > Fix For: 2.3.0rc3 > > Attachments: JAMES-609.diff > > > The change introduced in rc2 to fix the file leaks has produced an NPE in a > custom mailet. > I suggest to revert the setMessage changes removing the dispose() call for > the old message and to put the dispose code in the bundled calling mailets. > This is not a good fix in the long term, but for 2.3.0 I would prefer to keep > compatibility with 2.2.0 and to have a leak instead of NPE (difficult to > understand by most users). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
