3 Replies Latest reply on May 24, 2004 8:41 AM by adrian.brock

    MDB to talk to remote queue via HTTP tunelling

    andre_v

      Before I am going to great lengths explaining my problem.

      I just want to know whether it is possible for an MDB to listen on a remote queue using HTTP tunelling.

      If it is possible is there any special way of configuring it ?? Apart from the other well documented way.

      I tried by changing the settings to :

      <attribute name="ProviderUrl">http://whatever/invoker/JNDIFactory</attribute>
       <attribute name="QueueFactoryRef">HTTPConnectionFactory</attribute>


      I would suppose one would need to configure the InitialContext as well?? But where ??

      Connecting to the same remote Queue via HTTP from a plain JMS client works fine, but a MDB using the same remote queue no luck.

      Any ideas ?

      Andre


        • 1. Re:  MDB to talk to remote queue via HTTP tunelling

          You will have to implement a new version of JBossMQProvider.

          The default implementation assumes uses the jnp/rmi factory.
          http://cvs.sourceforge.net/viewcvs.py/jboss/jboss/src/main/org/jboss/jms/jndi/JBossMQProvider.java?rev=1.9&view=auto

          • 2. Re:  MDB to talk to remote queue via HTTP tunelling
            tmjkeeney

            I had to solve this problem recently and would like to contribute a new class, HttpJBossMQProvider, providing HTTP-based lookups to JBossMQ connection factories. The implementation was rather easy, since you only have to modify the current JBossMQProvider code slightly to enable HTTP-based lookups. Since I do not have committer privileges on the src tree, I'll just post it here. I hope this helps others addressing the same problem.

            --Tom

            package org.jboss.jms.jndi;
            
            import java.util.Hashtable;
            
            import javax.naming.ConfigurationException;
            import javax.naming.Context;
            import javax.naming.InitialContext;
            import javax.naming.NamingException;
            
            import org.jboss.logging.Logger;
            
            /**
             * A JMS provider adapter for <em>JBossMQ</em> using HTTP-based JNDI.
             * The JMS provider loader MBean must declare the URL to the HttpInvoker
             * JNDIFactory Servlet in the "ProviderUrl" attribute.
             */
            public class HttpJBossMQProvider extends AbstractJMSProviderAdapter
            {
            
             /** The initial context factory to use. */
             public static final String INITIAL_CONTEXT_FACTORY =
             "org.jboss.naming.HttpNamingContextFactory";
            
             /** Instance logger. */
             private transient Logger log = Logger.getLogger(this.getClass());
            
            
             /**
             * Default no-argument constructor.
             */
             public HttpJBossMQProvider()
             {
             log.debug("initializing");
             }
            
             /** Override of standard de-serialization to re-create logger. */
             private void readObject(java.io.ObjectInputStream in)
             throws java.io.IOException, ClassNotFoundException
             {
             in.defaultReadObject();
             this.log = Logger.getLogger(this.getClass());
             }
            
             /**
             * Create a new InitialContext suitable for this JMS provider.
             *
             * @return An InitialContext suitable for this JMS provider.
             *
             * @throws NamingException Failed to construct context.
             */
             public Context getInitialContext() throws NamingException
             {
             boolean debug = log.isDebugEnabled();
            
             if (providerURL == null)
             {
             throw new ConfigurationException("no ProviderUrl specified");
             }
            
             Hashtable props = new Hashtable();
             props.put(Context.INITIAL_CONTEXT_FACTORY,
             INITIAL_CONTEXT_FACTORY);
             props.put(Context.PROVIDER_URL, providerURL);
            
             if (debug)
             {
             log.debug("connecting to remote HTTP-based JNDI with props: " + props);
             }
            
             Context ctx = new InitialContext(props);
            
             if (debug)
             {
             log.debug("created context: " + ctx);
             }
            
             return ctx;
             }
            
            }
            


            • 3. Re:  MDB to talk to remote queue via HTTP tunelling

              Hi Tom,

              Thanks for your post. Others should find this useful in 3.2.3 and before.

              FYI: I have already changed the way this works in 3.2.4
              You now specifiy all the properties if you don't want the default in memory
              jndi connection.
              This should also make it easier to connect to thirdparty JMS solutions.
              e.g.

               <mbean code="org.jboss.jms.jndi.JMSProviderLoader"
               name="jboss.mq:service=JMSProviderLoader,name=JMSProvider">
               <attribute name="ProviderName">DefaultJMSProvider</attribute>
               <attribute name="ProviderAdapterClass">
               org.jboss.jms.jndi.JNDIProviderAdapter
               </attribute>
               <!-- The queue connection factory -->
               <attribute name="QueueFactoryRef">XAConnectionFactory</attribute>
               <!-- The topic factory -->
               <attribute name="TopicFactoryRef">XAConnectionFactory</attribute>
               <!- Use HAJNDI to access JMS -->
               <attribute name="Properties">
               java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
              
               java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces
              
               java.naming.provider.url=localhost:1100
               </attribute>
               </mbean>
              


              The old method still works in 3.2.x, but will be dropped for JBoss4