james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: Let's just tell Sun to rewrite the JavaMail API. Was: What about IMAP support?
Date Fri, 14 Nov 2003 20:42:12 GMT
Bill Shannon wrote:
> > One detailed reason I find MimeMessage less than ideal is that Message
> > contains the method saveChanges(), and Method.saveChanges() re-writes
> > Message-ID header.

> > The alternative, the compromise position I'd like to propose is this:
> > > Message.saveChanges() remains unchanged, but internally the action is
> > carried out by calling two methods, actionMimeChanges(), which would
> > and correct the Mime headers (like content transfer encoding and the
> > version header) and do any persisting which might be required and
> > updateMessageID()

> This is worth considering for the next JavaMail API revision.

> How about something like this...

> Currently MimeMessage.saveChanges calls MimeMessage.updateHeaders, which
> (among other things) calls setHeader to set a new Message-ID header.  It
> would be easy to move that setHeader call into a new protected
> updateMessageID method.

Currently we subclass MimeMessage and specialize updateHeaders.  I need to
make changes there because loading the message into memory is often
unacceptable, but the concept is sound.

Let me also remind you that we have had a proposal on the table since March:

  public void saveChangesExcept(String[] exceptionList)
  throws MessagingException


  mm.saveChangesExcept(new String[] { "Message-ID" });

which matches precisely the behavior supported by the analogous writeTo


> This does point out another workaround with the current implementation.
> You can override the setHeader method and only allow setting the
> Message-ID header if it's not already set.

That's similar to what we do, and might be a bit cleaner.  The problem is
that we don't ALWAYS want to note change the Message-ID header.  That is
something better understood in application code, not the message class.

	--- Noel

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

View raw message