Mule-embedded:使用容器自己的jndiInitialFactory

Question

考虑以下骡子配置，并将骡子嵌入到Web（Java EE）应用程序中：

<jms:connector
        name="jmsConnector"
        connectionFactory-ref="jmsConnectionFactory"> <!-- From spring -->
        <!-- JNDI Name Resover here? -->
</jms:connector>
<flow name="mainTestFlow">
    <jms:inbound-endpoint connector-ref="jmsConnector" 
        queue="jms/MessageQueue" />
    <logger level="INFO" category="mule.message.logging" message="Message arrived." />
</flow>

jmsConnectionFactory是指Spring中定义的JMS连接工厂，来自：

<bean id="jmsConnectionFactory" class="org.springframework.jndi.JndiObjectFactoryBean">
    <property name="jndiName" value="jms/QueueConnectionFactory" />
</bean>

队列连接工厂已经过测试，并且正在工作。

jms/MessageQueue队列名称引用web应用程序web.xml文件中定义的resource-ref。这个JNDI引用在容器级别绑定到由应用服务器管理的javax.jms.Queue，并连接到适当的消息服务器(在本例中是ActiveMQ)。

然而，Mule并不将queue=“”属性视为JNDI目的地，而是视为队列名称本身。因此，当上述代码初始化时，它实际上在ActiveMQ中创建了一个名为“jms/MessageQueue”的新队列。我真正想要的是它从Web应用程序描述符中的JNDI引用中正确检索队列。

好吧，你可以说，我所要做的就是在JMS连接器上配置一个JNDI名称解析器，并向其添加jndiDestinations="true "和forceJndiDestinations="true "属性。

这是可以接受的：

<jms:default-jndi-name-resolver 
    jndiProviderUrl="tcp://localhost:1099"
    jndiInitialFactory="???"/>

真正的问题是，我不想将真正的初始上下文工厂类名放在 jndiInitialFactory 中，因为它会落入特定于容器的定义中。但是，我的应用程序有时部署到 JBoss 4.2.3 中，有时部署到 WebSphere 7 中。由于我们的开发过程，拥有2个配置和2个EAR包不是一种选择。

无论如何，是否有可能告诉Mule-ESB将当前容器（因为它处于嵌入式模式）假设为用于查找的默认JNDI初始工厂，或者提供一个“通用”JNDI初始工厂来识别容器的JNDI环境？这应该不是问题，因为Web应用程序可以引用它的容器JNDI环境而无需额外（甚至可见）配置。

如果不可能，我可以让我的jms： inbing-endpoint引用Spring中定义的javax.jms.Queue吗，就像jms：连接器引用JMS连接工厂一样？这实际上相当优雅和干净，因为Mule对Spring友好。

提前谢谢大家了！

解决办法

经过深思熟虑，我终于通过创建一个连接到Spring JNDI设施（例如JndiTemboard）的自定义JndiNameResolver来解决我的问题。这远非最佳解决方案，但我发现这是最不会干扰和篡改Mule和Spring内部复杂性的解决方案。

这就是说，这里有一个类：package com.filcobra.mule；

import javax.naming.NamingException;

import org.mule.transport.jms.jndi.AbstractJndiNameResolver;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.beans.factory.InitializingBean;
import org.springframework.jndi.JndiObjectLocator;
import org.springframework.jndi.JndiTemplate;

public class SpringJndiNameResolver extends AbstractJndiNameResolver implements InitializingBean {
    private static Logger logger = LoggerFactory.getLogger(SpringJndiNameResolver.class);
    private JndiTemplate jndiTemplate;

    @Override
    public void afterPropertiesSet() throws Exception {
        if (jndiTemplate == null) {
            jndiTemplate = new JndiTemplate();
        }
    }

    @Override
    public Object lookup(String name) throws NamingException {
        Object object = null;
        if (name != null) {
            logger.debug("Looking up name "+name);
            object = jndiTemplate.lookup(name);
            logger.debug("Object "+object+" found for name "+name);
        }
        return object;
    }

    public JndiTemplate getJndiTemplate() {
        return jndiTemplate;
    }

    public void setJndiTemplate(JndiTemplate jndiTemplate) {
        this.jndiTemplate = jndiTemplate;
    }
}

这样，配置就回到了通常的状态：

<spring:bean id="jndiTemplate" class="org.springframework.jndi.JndiTemplate" />

<jms:connector
        name="jmsConnector"
        connectionFactoryJndiName="java:comp/env/jms/MyConnectionFactory" <!-- from Resource-Ref -->
        jndiDestinations="true"
        forceJndiDestinations="true"
        specification="1.1" >

    <jms:custom-jndi-name-resolver class="com.filcobra.mule.SpringJndiNameResolver">
        <spring:property name="jndiTemplate" ref="jndiTemplate"/>
    </jms:custom-jndi-name-resolver>    
</jms:connector>

有了它，我终于能够不让我的Mule ESB安装绑定到特定的JMS供应商/实现。事实上，JMS（队列和工厂）配置都由应用服务器负责。

然而，有一件事仍然很奇怪。我希望JMSendpoint也使用我的Jndi名称解析程序，以便从资源引用或其Jndi名中查找队列，与连接工厂的查找方式相同。那根本不管用。我最终通过放置队列名称本身解决了这个问题，正如在JMS服务器中创建的那样：

<flow name="mainTestFlow">
    <jms:inbound-endpoint connector-ref="jmsConnector" queue="queue/myQueue"/> <!-- Queue Name, not JNDI Name -->

成功了。因此，我假设JMS连接器不尝试查找队列，而是简单地使用连接工厂（无论是否查找）直接访问JMS服务器。

问候！

Answer 1

我在源代码中看到了问题:基本上如果你提供一个外部创建的连接工厂，< code>jndiDestinations和< code > forceJndiDestinations 被强制设置为< code>false。

我最近对JNDI的研究还不够深入，无法为您的问题提供一个通用的解决方案，这确实是最好的解决方案。

我会尝试的是子类 org.mule.transport.jms.Jms11Support，在其中注入我的 Spring 查找队列，在内部重新连接以使用这些队列，最后，将其注入 Mule JMS 连接器本身。