Interface MailerSpecProvider

Functional Interface:
This is a functional interface and can therefore be used as the assignment target for a lambda expression or method reference.
@FunctionalInterface public interface MailerSpecProvider

MailerSpec 的來源（消費端的接點）

契約

框架需要的只有兩個問題：「當前範圍的預設設定是什麼」與「這個名字的設定是什麼」。 怎麼存（JPA / 外部設定服務 / 記憶體）、要不要存、租戶怎麼隔離、誰能改、API 長什麼樣—— 全是消費端的事，框架一概不問。

「範圍」也是消費端的事。 框架沒有 scope 的概念——「當前是哪個範圍」「範圍明不明確」 由實作自行判定。範圍不明確時（如租戶模式下無 TenantContext ＝ root ＝ 看得見所有租戶） 必須回 Optional.empty()，不可任選一筆——那會靜默取用他人的寄件憑證。

不提供實作時

沒有 MailerSpecProvider 時，RoutingMailer 只用系統預設 Mailer（消費端組態依 設定檔建立）。郵件功能照常可用——不需要郵件設定管理的專案，成本為零。

實作提示

  • 回傳的 MailerSpec.revision 必須「內容變了就變」（lastModifiedDate / @Version 皆可）， RoutingMailer 據此自動重建 Mailer；消費端因此不需要在異動後清快取
  • 兩個方法都可能被頻繁呼叫（每次寄信解析一次），實作應與一般查詢同等成本
  • 停用的設定應回 Optional.empty()，不要回一個「停用中」的 spec
  • 範圍不明確時兩個方法都應回 Optional.empty()（見上）

由消費端的 mail 組態（seam）接線——那本來就是消費端組合郵件能力的地方。

  • Method Details

    • currentDefault

      Optional<MailerSpec> currentDefault()

      當前範圍的預設設定

      「範圍」由消費端定義（租戶、組織、或全域單一）。無預設設定時回 Optional.empty()， RoutingMailer 會退回系統預設 Mailer。

    • byName

      default Optional<MailerSpec> byName(String configName)

      依名稱取得設定

      預設實作回 Optional.empty()——只需要單一預設設定的消費端不必實作具名查找。