[ http://issues.apache.org/jira/browse/JAMES-499?page=all ]
Stefano Bagnara resolved JAMES-499:
-----------------------------------
Resolution: Fixed
Assign To: Stefano Bagnara
Fixed both in trunk and v2.3.
Hope this doesn't introduce backward compatibility problems.
> Inconsistent usage of the lastUpdated field for Mail objects
> ------------------------------------------------------------
>
> Key: JAMES-499
> URL: http://issues.apache.org/jira/browse/JAMES-499
> Project: James
> Type: Bug
> Components: James Core, MailStore & MailRepository
> Versions: 2.2.0, 2.3.0, 2.4.0
> Reporter: Stefano Bagnara
> Assignee: Stefano Bagnara
> Fix For: 2.3.0, 2.4.0
>
> Currently the MailImpl object update its own lastUpdated everytime the
> writeObject is called:
> private void writeObject(java.io.ObjectOutputStream out) throws IOException {
> lastUpdated = new Date();
> out.writeObject(sender);
> ....
> }
> Imho this is NOT correct: writeObject is a serialization method. If I write
> an object and then I read it again I should have an equal object. THis is not
> the case having updated the lastUpdated.
> Furthermore this is not consistent in James because writeObject is called
> only when storing mails in file repositories but not when storing mails in db
> repositories.
> Currently the only places we update the date is in temporary failures of the
> RemoteDelivery.
> In 2.3 I moved lastUpdated to the Mailet's Mail object, so we should make it
> clear what the usage should be and we should decide when this field is
> updated and when it's not updated.
> Updating it in the SpoolRepository.store would make sense but we loose the
> ability to change the lastUpdated field and to keep track of it. So we should
> manage it at an higher level.
> I think that we should at least remote the lastUpdate change from the
> writeObject.
> We should also add a lastUpdated "update" when the remote delivery store
> messages to the outgoing spool and when spoolmanager updates messages in the
> spool.
> Any hint on this?
--
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]
