配置“目录”以允许 WebSphere JNDI 查找

Question

我们目前正在开发一个部署在WebSphere服务器上的应用程序。该应用程序应该使用内部服务提供者，该服务提供者提供对作为远程EJB实现的服务的访问。服务提供者bean有一些硬编码的jndi名称可供使用。

现在在开发过程中，我们正在使用Tomee，总的来说一切都运行良好。除了一件事：ServiceProvider对“cell/持久/confiService”进行jndi查找。现在我尝试创建一个包含这些服务的模拟EJB的模拟耳朵。我能够部署它们，并且能够使用jndi名称从应用程序访问它们，例如：“java： global/frameme-mock-ear-1.0.0-SNAPSHOT/frame-mock-impl/ConfigServiceMock”，但似乎不可能使用jndi查找：“cell/持久/confiService”…现在我在模拟实现中添加了一个openejb-jar.xml文件，其中包含：

<openejb-jar>
    <ejb-deployment ejb-name="ConfigServiceMock">
        <jndi name="cell/persistent/configService"
              interface="de.thecompany.common.services.config.ConfigService"/>
    </ejb-deployment>
</openejb-jar>

在启动过程中，我可以看到bean似乎以该名称正确注册:

INFORMATION: Jndi(name=cell/persistent/configService) --> Ejb(deployment-id=ConfigServiceMock)

但是我现在知道如何让另一只耳朵能够使用这个名称访问这个bean。

服务提供商部分已经给出，我们根本无法更改，因此请不要建议更改硬编码的jndi名称。我们当然愿意这样做，但无法改变任何事情。

Answer 1

我知道这个问题几年后会有答案，但是一个更简单的解决方案是简单地设置系统属性如下(比如在catalina.properties中):

java.naming.initial.factory=org.apache.openejb.core.OpenEJBInitialContextFactory

这允许您通过设置的名称查找ejb，以及在启动期间在tomee日志中显示的名称，例如您的“cell/持久/confiService”

INFORMATION: Jndi(name=cell/persistent/configService) --> Ejb(deployment-id=ConfigServiceMock)

通过设置系统属性，您可以按照您想要的方式查找ejb

final Context ctx = new InitialContext();
ctx.lookup("cell/persistent/configService")

OpenEJBInitialContextFactory允许访问本地EJB和容器资源。

如果您不想设置系统属性（因为它会影响本书中的所有应用程序），您仍然可以使用工厂设置的“标准”方式：

    Properties properties = new Properties();
    properties.setProperty(Context.INITIAL_CONTEXT_FACTORY, "org.apache.openejb.core.OpenEJBInitialContextFactory");
    final Context ctx = new InitialContext(properties);
    ctx.lookup("cell/persistent/configService");

当然，您仍然可以使用全局“java： global/”以及该工厂查找它们。

Answer 2

好的……我在这上面浪费了很多时间。直到我终于想出了一个解决方案。我没有配置Tomee和OpenEJB来查找我的bean，而是劫持了LaunalContext并重写了我的查询。

package de.mycompany.mock.tomee;

import org.apache.naming.java.javaURLContextFactory;

import javax.naming.Context;
import javax.naming.NamingException;
import java.util.Hashtable;

public class MycompanyNamingContextFactory extends javaURLContextFactory {

    private static Context initialContext;

    @Override
    public Context getInitialContext(Hashtable environment) throws NamingException {
        if(initialContext == null) {
            Hashtable childEnv = (Hashtable) environment.clone();
            childEnv.put("java.naming.factory.initial", "org.apache.naming.java.javaURLContextFactory");
            initialContext = new MycompanyInitialContext(childEnv);
        }
        return initialContext;
    }

}

通过设置系统属性

java.naming.factory.initial=de.mycompany.mock.tomee.MycompanyNamingContextFactory

我能够注入我的MycompanyInitialContext上下文实现：

package de.mycompany.mock.tomee;

import org.apache.openejb.core.ivm.naming.IvmContext;
import org.apache.openejb.core.ivm.naming.NameNode;

import javax.naming.NamingException;
import java.util.Hashtable;

public class MycomanyInitialContext extends IvmContext {

    public MycomanyInitialContext(Hashtable<String, Object> environment) throws NamingException {
        super(environment);
    }

    @Override
    public Object lookup(String compositName) throws NamingException {
        if("cell/persistent/configService".equals(compositName)) {
            return super.lookup("java:global/mycompany-mock-ear-1.0.0-SNAPSHOT/mycompany-mock-impl/ConfigServiceMock");
        }
        if("cell/persistent/authorizationService".equals(compositName)) {
            Object obj = super.lookup("java:global/mycompany-mock-ear-1.0.0-SNAPSHOT/mycompany-mock-impl/AuthServiceMock");
            return obj;
        }
        return super.lookup(compositName);
    }

}

我知道这并不漂亮，如果有人知道如何使这变得更容易和更漂亮，我洗耳恭听，这个解决方案似乎很有效。因为它只是为了在开发过程中模拟生产服务，所以这个黑客不会给我带来任何噩梦。我只是想把它贴出来，以防其他人发现类似的事情。