jakarta-ee - Java EE 中的 InitialContext 相对于mappedName 有什么用处？

Question

我不明白什么时候有人会使用 (new InitialContext()).lookup(....) 而不是

@Stateless(mappedName="A1Global")
public class A1 implements A { ... }

@EJB(mappedName="A1Global")
private A a;

后一种使用mappedName的方法有什么缺点吗？我还注意到 JNDI 名称可能是特定于供应商的、复杂的且不必要的长。

Answer 1

通过 JNDI 获取 EJB 在不受依赖项注入(inject)容器管理的类中可能很有用，因此 @EJB 根本不起作用。然而，这些情况很少见，通常是由与您想要使用 @EJB 的客户端框架相关的规范中的错误或疏忽引起的，并且应该在该客户端框架的较新版本，以便最终可以仅使用 @EJB。

例如，JSF(Java EE 的 MVC 框架)支持自定义转换器和验证器。但是，由于疏忽，自定义 JSF Converter 或 Validator 不支持 @EJB，而它们有时可能需要调用业务服务电话。这个问题在 JSF 2.3 中得到了解决，但在那之前，一种解决方法是通过 JNDI 获取 EJB——尽管这相当笨拙，但还有更简单的解决方法，另请参阅 a.o How to inject @EJB, @PersistenceContext, @Inject, @Autowired, etc in @FacesConverter?

同样的情况也发生在 Bean Validation(Java EE 的验证框架)上。直到版本 1.1 之前，自定义 ConstraintValidator 才支持 @EJB。另请参见 a.o. JSF 2.0 validation in actionListener or action method .

JNDI 名称适用于不特定于供应商的 EJB。至少，Java EE 中没有这样规定。然而，它特定于 EJB 的打包方式以及 EJB 客户端在应用程序中的位置。此相关问题的答案解释了 JNDI 名称的组成方式以及您应该根据 EJB 客户端的位置使用哪个名称: Inject EJB bean from JSF managed bean programmatically .

简而言之，如果您可以使用@EJB，那么一定要使用它。如果你做不到，那么首先研究一下你是否以正确的方式做事。有时，人们试图在完全没有意义的地方获取 EJB。如果您可以确认您不是唯一在使用 @EJB 来实现所需功能要求时遇到问题的人，请向相关客户端框架报告问题。他们很有可能在指定位置添加 @EJB 支持。

也就是说，如果您的环境支持 CDI，那么您需要知道目前建议将 @EJB 迁移到 @Inject。在 Java EE 6/7 中，除了一种极端情况(EJB 循环注入(inject)自身)之外，它会正常工作。 CDI 的目标是将整个 Java EE 框架中的所有各种依赖注入(inject)机制统一到一个 API 中。例如，JSF 已经计划弃用其 @ManagedBean/@ManagedProperty，转而使用 @Named/@Inject在未来的 Java EE 版本中。另请参见 a.o. Backing beans (@ManagedBean) or CDI Beans (@Named)?对于 @EJB 可能会发生同样的情况，有利于 @Inject。