2 Replies Latest reply on Jun 8, 2006 3:46 AM by Michael Barker

    MailHeadersImpl refactoring

    Michael Barker Apprentice

      I have created a new version of MailHeadersImpl, which seems to be working ok. I am a little hesitent to commit it right now as M5 is imminent and it could destablise JBMS a little. It also needs more testing (especially in the areas of header folding and replacing LineInputStream). So for the time being I am holding off until M5-final is released.

      The new version maintains 3 lists of MailHeader objects (trace, resent and other) to preserve the appropriate order and a map of keys to headers to create a fast index. I looked at the comment on the top of the existing MailHeadersImpl which mentioned using map and maintaining a list of keys to determine order. This would mean all headers of the same name would be output together. Unfortunately the section in the rfc regarding resent headers disallows this. Resent headers need appear in blocks and can not be reordered.

      Some of the key things I have changed:

      - Creation of header entries, i.e. stream parsing is seperated into seperate static factory methods.
      - Removed dependency on SMTPProtocolInstance. This I would like to further this by moving functionality like checkForLoops into the SMTPProtocol, where it is more relevant.
      - Dependency on javamail packages mostly removed (in the process of writing a replacement for LineInputStream).

      Once I have this fully wrapped up I would like to apply similar refactoring to the Mail class. I would like remove all parsing from the Mail constructor and make the Mail object simply an aggregation of Headers, Bodies and some envelope information. All of the stream handling, header creation, etc. should be the domain of static factory methods or the part module that is creating the Mail (e.g. JCA adaptor).

      Potentally once that is done, I might have a look at seperating the Mail from the Envelope.