我正在使用最近从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