2011-05-21 133 views
1

我想在Spring.NET中配置一個能夠讀取其他配置文件的對象。這些文件應該相對於Spring.NET配置文件(或者如果Spring.NET配置文件位於app.config)。檢索在Spring.NET中配置對象的配置文件路徑

所以我需要的是一種方法來找出我的對象的對象定義來自哪個配置文件。或者如果沒有配置文件(因爲它已被編程配置)。

如果沒有通用的解決方案(恐怕沒有一個...),那麼專門針對XmlApplicationContext的解決方案也可以。

我到現在爲止的嘗試是從IApplicationContextAware派生,然後將應用上下文轉換爲XmlApplicationContext。這包含屬性ConfigurationLocations。 但是,這並不因爲ConfigurationLocations工作

  • 被保護,因此無法訪問
  • 是文件的數組所以如果有一個以上的文件,我不知道從哪個我物體進入
  • 具體
  • 到XmlApplicationContext(如說:好吧,但不是最佳)
  • 我敢肯定,如果配置是在app.config內,這將無法正常工作。

有沒有解決我的問題?

+0

你能否解釋爲什麼你需要閱讀這些配置文件?也許有另一種解決方案。 – Marijn 2011-05-21 11:48:44

+0

我只能想到黑客......我會把文件名放在外部對象的DI配置中,這是最乾淨的解決方案IMO。 – Marijn 2011-05-22 12:39:27

回答

1

我可以確認,無法將爲Context定義的特定對象的ObjectDefinition與Ob​​jectDefinition的特定「源」註冊後關聯起來。

Context的基礎ObjectFactory的設計特別是這樣的,它不需要知道/關心ObjectDefinition元數據的起源位置,而是在初始化ObjectFactory時將所有元數據合併在一起。

雖然這可能適用於您的具體使用情況,但我會留意有關「保持跟蹤」配置文件路徑的信息,它不太可能成爲問題的良好通用解決方案b/c Spring.NET配置文件設計的一個重要原則是一個配置文件可以「導入」一個或多個其他配置文件,這些配置文件又可以導入一個或多個其他配置文件等,並且知道完整路徑這些相互依賴的配置文件將不會(必然)與包含您正在尋找的特定對象的元數據的實際配置文件的路徑有任何關係。同樣,如果你完全控制了配置文件的格式/內容,那麼你的解決方法可能是可行的,但要注意它可能不是一個好的通用解決方案。

+0

如果您的「包裝器」從「XMLApplicationContext」繼承而來,您將有權訪問......但我不確定是否需要這樣做。 – Marijn 2011-05-23 13:24:54