我正在使用最近從EJB2遷移到EJB3的無狀態會話bean的大型遺留應用程序，並且我想使用依賴注入。不幸的是，在一個（IMO誤導）嘗試實現解耦的過程中，所有實際的業務邏輯都在於會話bean向其轉發呼叫的「經理」類。那些管理器類常常使用其他EJB。我可以在Java EE中使任意類「注入」嗎？
我可以通過@Resource以某種方式使這些管理器類能夠注入到EJB中，然後通過@EJB將其他EJB注入到EJB中嗎？
該應用程序必須在glassfish 2.1上運行。
（...）所有實際的業務邏輯都在於會話bean將呼叫轉移到的「經理」類。
這是一個非常常見的EJB 2.x模式，允許在容器外輕鬆地單元測試「管理器」類，而無需遵守任何EJB API。
我能以某種方式使這些管理器類能夠通過@Resource注入到EJB中，然後讓其他EJB通過@EJB注入到它們中嗎？
不超出現成使用Java EE 5.注射僅限於在Java EE平臺定義的第一類構造，包括：
SessionContext對象DataSources對象UserTransactionEntityManager接口TimerService個接口在Java EE 6中，這一點使用CDI（JSR-199）和@Inject註解在EJB中注入你的經理，並在你的經理獲得EJB的注入將成爲可能。
也許你可以嘗試部署Weld（JSR-199的RI）作爲在GlassFish v2.1的應用程序的一部分。我沒有親自嘗試，所以我什麼也沒有證實。以防萬一，也許看看Chapter 18. Application servers and environments supported by Weld（GlassFish v2.1尚未經過測試，但並不意味着它不起作用）。
帕斯卡關於升級到GlassFish 3的建議聽起來可能就像是最優雅的方法;） 我會好奇聽到什麼阻止移動到更新的版本（並不是說沒有理由，只是想知道什麼問題在這裏）。
大公司對於軟件更改（包括升級）可能非常保守。有（如我的情況）有一個允許使用的「已批准」軟件列表並不罕見，而獲得該列表需要進行一系列測試和試用，這些測試和試用可能需要一年或兩年（90％那段時間是純粹的奢侈品開銷）。當然，只有當有人有足夠的耐力和預算才能看到它時纔會發生。 – 2010-06-24 10:51:48
謝謝邁克爾。我想知道在當前3.x版本中是否缺少集羣是一個問題？另外，我最近看到一些公司採用雙應用程序服務器策略，將GlassFish用作更靈活，約束更少的解決方案（因此減少官僚主義以驗證其使用）。 – 2010-06-29 07:06:40
呃，那就是我所害怕的。將研究Weld，但這是一個企業環境（這是Glassfish 2的原因），它可能不被允許。 – 2010-06-17 20:33:41
至少你有玻璃魚所以升級至少是_possible_ :)順便說一句，焊接可以在servlet 2.5環境中運行。 – 2010-06-21 13:43:45