类路径上多个 jndi.properties 的排序
我有一个 jboss Web 服务，它获取了错误的初始上下文。我希望它使用服务根目录中的jndi.properties中的java.naming.factory.initial，而不是jboss jndi.properties<中的java.naming.factory.initial /code> 是 NamingContextFactory。在 ant 构建文件中，我将 jndi.properties 放入类路径中，并确保它复制到存档中，但服务仍然获取 NamingContextFactory 。我如何知道使用了哪个 jndi.properties 以便正确设置工厂？
不幸的情况是，我必须使用一个第三方 jar，它期望其初始上下文工厂是其打包的 jndi.properties 文件中指定的工厂，但是当我在 jboss 中运行它时，它会得到 <代码>NamingContextFactory。我无法在不破坏所有内容的情况下更改 jboss jndi.properties 文件。
I have a jboss web service that is getting the wrong initial context. I want it to use the java.naming.factory.initial from the jndi.properties in the services root directory and not the one in jboss jndi.properties which is the NamingContextFactory. In the ant build file I put the jndi.properties in the classpath and made sure it copies over to the archive, but the service still gets the NamingContextFactory instead. How can I tell which jndi.properties gets used so that the factory gets set correctly?
The unfortunate situation is that I have a third party jar I must use that expects its initial context factory to be the one specified in its packaged jndi.properties file, but when I run this in jboss it gets NamingContextFactory. I can't change the jboss jndi.properties file without everything breaking.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果类路径根目录中有多个 jndi.properties 文件，那么 InitialContext 会尝试合并这两个文件，但哪一个获胜或多或少是个问题的机会。
如果您想确定，那么
InitialContext有一个构造函数，它采用属性的Hashtable，您可以在其中显式指定它们。在这种情况下，这比通过 jndi.properties 隐式加载更好。您始终可以将目标jndi.properties加载到Properties对象（它是Hashtable的子类）中，并将其传递给构造函数。If you have multiple
jndi.propertiesfiles in the root of the classpath, thenInitialContextwill make some attempt to merge the two, but which one wins is more or less a matter of chance.If you want to make sure, then
InitialContexthas a constructor that takes aHashtableof properties, where you can specify them explicitly. That would be preferable to implicit loading viajndi.properties, in this case. You can always load your targetjndi.propertiesinto aPropertiesobject (which is a subclass ofHashtable), and pass that to the constructor.