我上週在客戶現場，人群中有人問：「為什麼 getConfigLocations() 不再是 abstract 了？」 在客戶面前工作一段時間後，變得很少會說不出話來，但我當時卻是。 老實說，我的第一個想法是客戶不可能說的是對的。 但是，瞧，在 AbstractSingleSpringContextTests 的 revision 1.3 中，清楚地說明 getConfigLocations() 不再是 abstract。 我沒有針對 2.0.1 建立任何新的整合測試，所以我甚至沒有看到這個變更。

我對此感到驚訝，所以我發了一封電子郵件給 Juergen，想知道發生了什麼事，這是他所說的。

這個變更是為了那些覆寫 "contextKey()" 和 "loadContext(Object)" 的人，他們取得某種其他形式的 ApplicationContext (不是預設的 ClassPathXmlApplicationContext)。 在這種情況下，"getConfigLocations()" 就沒有意義了，因為它只與 "contextKey()" 的預設實作有關。 因此，任何覆寫這些 hook 的人都必須提供一個空的 "getConfigLocations()" 方法，這有點愚蠢... 如果我們一直希望人們提供 config locations，我們就不應該首先公開那些受保護的 "contextKey()" 和 "loadContext(Object)" 方法。

所以簡短的說，您仍然可以像以往一樣覆寫 getConfigLocations() 方法，只是您不會再有 abstract 方法的提醒。

特別感謝 Gregory Kick 提出這個問題。