Websphere 7 中的 EJB3 beans JNDI 查找

发布于 2024-09-15 12:26:37 字数 407 浏览 8 评论 0原文

我创建了一个带有 Web 项目、ejb3 项目和 ejb 客户端的 EAR。我可以通过 servlet 中的注入来调用 bean 方法。 我计划使用 ServiceDelegate 它是一个 pojo 来处理 bean 调用。因此,我将从 servlet 中调用委托,委托将调用适当的 bean 及其方法。

但我无法获取 Web 项目中的委托类中的 bean 引用。 @EJB 注释返回空引用。因此,我尝试使用 java:comp/env/EARname/BeanName 进行 JNDI 查找。但我总是以命名例外告终。

在上下文“java:”中找不到名称 comp/env/EARname。

请建议我在 Websphere 7 服务器上通过 JNDI 调用 ejb3 beans 的正确方法。

I have created an EAR with a web project, ejb3 project and the ejb client. I'm able to call the bean methods via injection in the servlet.
I'm planning to use a ServiceDelegate which is a pojo to handle the bean invocation. So I'll call the delegate from my servlet and the delegate will call the appropriate beans and its methods.

But I'm unable to get the bean references in the delegate class which is in the web project. @EJB annotation returned a null reference. So I tried a JNDI lookup with java:comp/env/EARname/BeanName. But I always end up with naming exceptions.

Name comp/env/EARname not found in context "java:".

Please suggest me the correct way to call ejb3 beans via JNDI on Websphere 7 server.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

街道布景 2024-09-22 12:26:37

Java EE 5 和 6 中的依赖注入仅适用于托管类。在 servlet 容器中,少数类型的类支持这一点,但并非所有 POJO 都支持(不幸的是)。

Servlet 规范 2.5 阐明了容器必须为其注入依赖项(如果存在)的类:


组件类型:Servlet

实现以下接口的类

  • javax.servlet.Servlet

< strong>组件类型:过滤器

实现以下接口的类

  • javax.servlet.Filter

组件类型:监听器

实现以下接口的类 >:

  • javax.servlet.ServletContextListener
  • javax.servlet.ServletContextAttributeListener
  • javax.servlet.ServletRequestListener
  • javax.servlet.ServletRequestAttributeListener
  • javax.servlet.http.HttpSessionListener
  • javax.servlet.http.HttpSessionAttributeListener

因此,如果您必须通过依赖项查找来解决问题,您可以可以采用以下任一策略:

  • 将依赖项注入到托管类中,并将其传播到 ServiceDelegate。恕我直言,这是一种设计味道。
  • 使用 InitialContext 执行 JNDI 查找,但您应该了解为已部署的 EJB 生成的 JNDI 绑定。这似乎失败了,因为 JNDI 名称可能不正确 - Java EE 规范尚未标准化分配给已部署 EJB 的 JNDI 名称。换句话说,由于缺乏可移植的 JNDI 名称,您应该尝试将 EJB 绑定到已知名称并执行相同名称的查找。
  • 您需要验证 EJB 会话对象确实绑定到 java:comp/env 命名空间。情况可能并非如此。需要明确的是,如果依赖项不是由容器注入的,则必须在 web.xml 中声明本地 EJB 引用条目。容器不会自动将会话 EJB 对象注入到 servlet 的命名空间中;它将要求将 EJB 声明为托管类中的资源。这似乎是主要的失败案例,尽管它被列在最后。

Dependency injection in Java EE 5 and 6, works only for managed classes. In the servlet container, this is supported in a few types of classes, and not in all POJOs (unfortunately).

The Servlet Spec 2.5 sheds light on the classes for which the container must inject dependencies if they are present:


Component Type: Servlets

Classes implementing the following interfaces

  • javax.servlet.Servlet

Component Type: Filters

Classes implementing the following interfaces:

  • javax.servlet.Filter

Component Type: Listeners

Classes implementing the following interfaces:

  • javax.servlet.ServletContextListener
  • javax.servlet.ServletContextAttributeListener
  • javax.servlet.ServletRequestListener
  • javax.servlet.ServletRequestAttributeListener
  • javax.servlet.http.HttpSessionListener
  • javax.servlet.http.HttpSessionAttributeListener

Therefore, if you have to resolve the issue with dependency lookups, you could adopt either of the following strategies:

  • Inject the dependency into a managed class, and propagate it to the ServiceDelegate. This is a design smell IMHO.
  • Perform a JNDI lookup using the InitialContext, but you should be aware of the JNDI bindings generated for the EJBs that you have deployed. This appears to be failing since the JNDI name might be incorrect - the Java EE specification has not standardized the JNDI names that are assigned to the deployed EJBs. In other words, given the lack of portable JNDI names, you should attempt to bind the EJB to a known name and perform a lookup of the same.
  • You'll need to verify that the EJB session object is indeed bound to the java:comp/env namespace. This might not be the case. To be clear, if the dependency is not injected by the container, then one must declare the local EJB reference entries in web.xml. The container will not automatically inject the session EJB objects into the servlet's namespace; it will require the EJB to be declared as a resource in a managed class. This appears to be the primary case of failure, although it is listed last.
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文