Subversion Repositories SmartDukaan

Last modification

• Rev 37477 – 21 d 17 h
• Author: amit

• Log message:

  mail: one way to send mail, and nothing sends inline
  
  There were three overlapping APIs -- Utils.sendMail* (7 static overloads),
  EmailServiceImpl.sendMail* (7 more) and MailOutboxService.queueMail* (20). The
  first two built their own MimeMessage, hardcoded From: noreply@smartdukaan.com
  in eleven places, and pushed straight down whichever JavaMailSender the caller
  passed.
  
  That From is why mail was refused: an authenticated Workspace session may send
  only as the account it logged in as, and noreply@ is a different identity in the
  same domain. Sending inline also meant a failed send was lost outright and took
  the calling job down with it, which is how one expired credential came to mark
  ten report jobs FAILED.
  
  New in profitmandi-common:
  MailQueue - the single entry point; queue() returns once the mail is
  recorded, not once it is sent
  MailRequest - one value object replacing the 34 overloads
  MailSenderType - GOOGLE (authenticated, From rewritten) or RELAY (IP-authorised)
  
  The interface lives in common while MailOutboxService implements it in dao,
  because dao depends on common and not the reverse -- Utils and EmailService
  could not otherwise reach the outbox at all.
  
  Utils and EmailService keep their signatures so the ~38 call sites still
  compile, but now delegate and ignore the JavaMailSender argument; choosing a
  transport was never the caller's business. Both are marked deprecated.
  MailQueueHolder bridges the static helpers to the bean and is documented as a
  compromise, not a pattern.