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

问题描述

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

支持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类提供了从提供者对Context的访问，并且 提供程序使用静态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.

在嵌入式方案中，可能在执行JNDI调用的OSGI容器内部和外部都存在应用程序代码，并且当它们在同一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意识代码像往常一样执行其JNDI调用，还是需要移植到"OSGI意识"? ?

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中部署了战争，将所有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启动在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中，而不是OSGI上如何管理JNDI查找的问题.

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屋！