OSGI JNDI 是否允许与来自非 OSGI 代码的 JNDI 调用共存? [英] Does OSGI JNDI allow coexistence with JNDI calls from non-OSGI code?

查看:33
本文介绍了OSGI JNDI 是否允许与来自非 OSGI 代码的 JNDI 调用共存?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

OSGI Enterprise Release 5 规范的第 126 章提到了兼容性:

Chapter 126 of the OSGI Enterprise Release 5 specification mentions compatibility:

支持 Java SE 和 Java EE 客户端使用的传统 JNDI 编程模型."

"Support the traditional JNDI programming model used by Java SE and Java EE clients."

和使用不支持 OSGI 的代码:

and use of OSGI-unaware code:

"不知道 OSGi 的客户端和 JNDI 上下文提供程序使用静态方法连接到JRE JNDI 实现.InitialContext 类提供从提供者和提供者使用静态 NamingManager 方法进行对象转换和查找 URL 上下文.这种传统模型不知道 OSGi,因此只有在后果发生时才能可靠地使用对 OSGi 意识的缺乏进行了管理."

"Clients and JNDI Context providers that are unaware of OSGi use static methods to connect to the JRE JNDI implementation. The InitialContext class provides access to a Context from a provider and providers use the static NamingManager methods to do object conversion and find URL Contexts. This traditional model is not aware of OSGi and can therefore only be used reliably if the consequences of this lack of OSGi awareness are managed."

但我不清楚本文是否仅适用于在 OSGI 包内执行的遗留"代码,或者也适用于 OSGI 容器外的代码,例如在 OSGI 容器嵌入应用程序的情况下.

but it is not clear to me if this text only applies to "legacy" code executed inside an OSGI bundle, or also to code outside the OSGI container, f ex in a scenario where the OSGI container is embedded in an application.

在嵌入场景中,OSGI 容器的外部和内部可能都有执行 JNDI 调用的应用程序代码,并且当它们在同一个 JVM 中执行时,它们将共享 JNDI 实现.

In an embedding scenario, there may be application code both outside and inside the OSGI container that performs JNDI calls, and as they execute in the same JVM they will share JNDI implementation.

问题:在嵌入式 OSGI 容器中运行的 OSGI JNDI 实现是否应该允许容器外的 OSGI-unaware 代码像往常一样执行其 JNDI 调用,或者是否需要某种移植到OSGI-awareness"?

Question: Should an OSGI JNDI implementation running in an embedded OSGI container allow OSGI-unaware code outside the container to perform its JNDI calls like usual, or is some porting to "OSGI-awareness" required?

我自己用 Apache Karaf 2.3.0(使用 Apache Aries JNDI 1.0.0)尝试这个,这似乎不起作用,因为 Apache Aries 要求 JNDI 客户端调用源自 OSGI 包.
部分堆栈跟踪:

Trying this out myself with Apache Karaf 2.3.0 (which uses Apache Aries JNDI 1.0.0) this doesn't seem to work, as Apache Aries requires JNDI client calls to originate from an OSGI bundle.
Partial stacktrace:

javax.naming.NoInitialContextException: The calling code's BundleContext could not be determined.
    at org.apache.aries.jndi.OSGiInitialContextFactoryBuilder.getInitialContext(OSGiInitialContextFactoryBuilder.java:46)
    at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
    at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307)
    at javax.naming.InitialContext.init(InitialContext.java:242)
    at javax.naming.InitialContext.<init>(InitialContext.java:192)

问题:这种行为是否正确,或者是否有我可以参考的规范部分违反了此限制?

Question: Is this correct behaviour, or is there a section of the specification I can refer to that is violated by this limitation?

推荐答案

我在尝试在 Weblogic 上部署 Apache Karaf 时遇到了同样的问题.我们通过 servlet 桥使用 karaf - 在 weblogic 中部署了一个 war,它将所有 http 请求桥接到 karaf.

I ran into same issue when trying to deploy Apache Karaf on Weblogic. We use karaf through a servlet bridge - a war is deployed in weblogic which bridges all http requests to karaf.

我在 weblogic 上运行以下应用程序:

I am running with the the following applications on weblogic:

  1. app1(使用 JNDI)
  2. app2
  3. karaf-bridge(将请求桥接到 Karaf)

一旦 karaf 启动在 Karaf 中运行的 Aries JNDI 实现,就会将 javax.naming.NamingManager 中的 InitialContextFactoryBuilder 设置为它自己的实现.NamingManager 持有对初始上下文工厂构建器的静态引用,因此无论其是否在 OSGI 环境中运行,任何实现设置此静态引用都会成为 JNDI 提供者.

As soon as karaf starts the Aries JNDI implementation running inside Karaf sets InitialContextFactoryBuilder inside javax.naming.NamingManager to its own implementation. NamingManager holds a static reference to the initial context factory builder, so whichever implementation, irrespective of whether its running in an OSGI environment, sets this static reference becomes the JNDI provider.

在我的情况下,当 app1(非 OSGI)尝试执行新的 InitialContext 时,Aries JNDI 尝试使用 BundleContext 解决它并失败.

In my case when app1 (non-OSGI) tries to do a new InitialContext, Aries JNDI tries to resolve it using the BundleContext and fails.

我使用一些非常丑陋的技巧修复了这个问题,包括从 jre 中提取 javax.naming 包并将其作为包安装在 karaf 中.

I fixed this using some very ugly hacks that involved extracting the javax.naming package from jre and installing it as a bundle in karaf.

所以你的问题的答案是:我认为问题真的出在 jre 上,而不是关于如何管理 JNDI 查找的 OSGI.

So the answer to your question: I think the issue is really in the jre and not with OSGI on how JNDI lookup is managed.

这篇关于OSGI JNDI 是否允许与来自非 OSGI 代码的 JNDI 调用共存?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆