Jukka Zitting ha scritto: > OK. I guess the attributes can be any serializable objects, so the > implementation should use standard Java serialization in case it > doesn't know the type of the attribute.
Yes, Java serialization is the way to go. "public Serializable setAttribute(String key, Serializable object)" > Is the repository implementation required to keep the original key > (from mail.getName()) when stroring a new message, or can it replace > it with an internal identifier? It is not documented, so to be safe you should keep the name. On the other hand I'm almost sure (99%) our current codebase never keeps "references" to the name. The main problem with "repository generated keys" is that the current interface does not give you a way to know what key has been assigned to a stored message. Just make sure that if I call store for a mail with an existing key you update the same mail and do not create a new one. >> Maybe some of this things should be changed, I simply replied with what >> the current code does and expects. > > ACK. Thanks a lot for the help! You probably noticed that we currenlty have SpoolRepository and MailReposutory and that SpoolRepository is a MailRepository with some added method (every MailRepository could expose SpoolRepository services via a simple wrapper). We discussed many times about changing this so to have a MessageRepository that should be similar to the current MailRepository but only include mail.message (MimeMessage) informationd and an EnvelopeRepository (to replace SpoolRepository) that should only store the envelope (everything else you find in the Mail object but the MimeMessage) and reference a Message from a MessageRepository. (Maybe JCR better fits the MessageRepository and JMS better fits the EnvelopeRepository for their respective persistence natures) We never did that because this would break backward compatibility and current trunk is still storage+config.xml compatible with 2.3.0/2.3.1 releases. Imho backward compatibility is not a big issue: we should just take care to tag the last trunk version before "breaking" it. Thank you too, Stefano some related link, if you are interested: http://issues.apache.org/jira/browse/JAMES-521 http://www.mail-archive.com/[email protected]/msg04986.html http://www.mail-archive.com/[email protected]/msg07251.html http://www.mail-archive.com/[email protected]/msg07261.html http://www.mail-archive.com/[email protected]/msg07283.html --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
