6 Replies Latest reply on Jun 9, 2015 7:47 PM by George Berish

    Cannot obtain JMS ConnectionFactory

    George Berish Novice

      The code below was supposed to be a simple learning exercise that attemped JMS with WildFly. But it wasn't.  I couldn't get past getting a ConnectionFactory.


      WildFly is running on my PC. 

      I  run the java client from Eclipse Luna, also on my PC. 

      The WildFly properties (Servers Tab in Luna) show standalone-full.xml


      The code is overkill out of frustration.  I added a static String array to hold all the jndi names I tried. The main method just gets a context, and looks up all the names in the String array.  And it prints out what it's doing.


      I think I'm getting a context.  But all jndi names fail.  Although my 1st try -- which I read was the one that is supposed to work -- looks close.

      Any help or direction would be appreciated.

      CODE (output follows)


      package org.america3.go.client.controller.messages;

      import javax.jms.ConnectionFactory;

      import javax.naming.Context;

      import java.util.Properties;

      import javax.naming.InitialContext;


      public class SimpleTest2 {


        static String[] factoryLookupNames = {




          "java:/ConnectionFactory" };


        static public void main (String args[]) {

          Properties        jndiProps = null;

          Context           ctx = null;

          ConnectionFactory factory   = null;


          jndiProps = getjndiProperties ();

          ctx = getContext (jndiProps);

          // try all names

          for (String factoryName : factoryLookupNames) {

            factory = getFactory (ctx, factoryName);

            if (factory != null) break;



      static private Properties getjndiProperties () {

          try {

            Properties output = new Properties();

            output.setProperty (Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");

            output.setProperty (Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");

            output.setProperty (Context.PROVIDER_URL, "http-remoting://localhost:8080/");

            //This property is important for remote resolving

            output.setProperty ("jboss.naming.client.ejb.context", "true");

            //This property is not important for remote resolving

            output.setProperty ("org.jboss.ejb.client.scoped.context", "true");

            System.out.println("Local Connection Properties:");

            for (Object key:output.keySet()) {

              System.out.println("Key: " + (String) key + "  Value: " + output.getProperty((String) key) );


            return output;

          }catch (Exception e) {

           System.out.println("Error #1");

            return null;




        static private Context getContext (Properties jndiProps) {


            Context ctx = (Context) new InitialContext(jndiProps);

            System.out.println("\nSuccessfully obtained a Local WildFly server context");


            return ctx;

          } catch (Exception e) {

            System.out.println("Error #2");

            return null;




        static private ConnectionFactory getFactory (Context ctx, String jndiName) {


            System.out.println("\nAttempting to lookup: " + jndiName);

            ConnectionFactory rtnFactory  = (ConnectionFactory) ctx.lookup(jndiName);

            System.out.println("\nSuccessfully obtained ConnectionFactory from local WildFly server");


            return rtnFactory;

          } catch (Exception e) {

            System.out.println("Exception Message: " + e.getMessage());

            System.out.println("Exception Cause:   " + e.getCause());

            return null;







      Local Connection Properties:

      Key: java.naming.provider.url  Value: http-remoting://localhost:8080/

      Key: java.naming.factory.initial  Value: org.jboss.naming.remote.client.InitialContextFactory

      Key: jboss.naming.client.ejb.context  Value: true

      Key: java.naming.factory.url.pkgs  Value: org.jboss.ejb.client.naming

      Key: org.jboss.ejb.client.scoped.context  Value: true

      Jun 05, 2015 5:14:39 PM org.xnio.Xnio <clinit>

      INFO: XNIO version 3.3.0.Final

      Jun 05, 2015 5:14:39 PM org.xnio.nio.NioXnio <clinit>

      INFO: XNIO NIO Implementation Version 3.3.0.Final

      Jun 05, 2015 5:14:39 PM org.jboss.remoting3.EndpointImpl <clinit>

      INFO: JBoss Remoting version 4.0.6.Final


      Successfully obtained a Local WildFly server context

      1. javax.naming.InitialContext@6108b2d7


      Attempting to lookup: jms/RemoteConnectionFactory

      Jun 05, 2015 5:14:39 PM org.jboss.ejb.client.remoting.VersionReceiver handleMessage

      INFO: EJBCLIENT000017: Received server version 2 and marshalling strategies [river]

      Jun 05, 2015 5:14:39 PM org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver associate

      INFO: EJBCLIENT000013: Successful version handshake completed for receiver context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext@5700d6b1, receiver=Remoting connection EJB receiver [connection=Remoting connection <3310ea64>,channel=jboss.ejb,nodename=ace]} on channel Channel ID 92ba6449 (outbound) of Remoting connection 0f38d515 to localhost/

      Jun 05, 2015 5:14:45 PM org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver associate

      INFO: EJBCLIENT000015: Initial module availability report for Remoting connection EJB receiver [connection=Remoting connection <3310ea64>,channel=jboss.ejb,nodename=ace] wasn't received during the receiver context association

      Exception Message: jms/RemoteConnectionFactory -- service jboss.naming.context.java.jboss.exported.jms.RemoteConnectionFactory

      Exception Cause:   null


      Attempting to lookup: java:jboss/exported/jms/RemoteConnectionFactory

      Exception Message: jboss/exported/jms/RemoteConnectionFactory -- service jboss.naming.context.java.jboss.exported.jboss.exported.jms.RemoteConnectionFactory

      Exception Cause:   null


      Attempting to lookup: java:jboss/DefaultJMSConnectionFactory

      Exception Message: jboss/DefaultJMSConnectionFactory -- service jboss.naming.context.java.jboss.exported.jboss.DefaultJMSConnectionFactory

      Exception Cause:   null


      Attempting to lookup: java:/ConnectionFactory

      Exception Message: ConnectionFactory -- service jboss.naming.context.java.jboss.exported.ConnectionFactory

      Exception Cause:   null



      In case it helps here is the stack trace from the 1st failure:

      Stack Trace:






      java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)

      java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)

      java.lang.Thread.run(Unknown Source)

        • 1. Re: Cannot obtain JMS ConnectionFactory
          jaikiran pai Master


          That's the right JNDI name to use for remote lookup. But your logs show that it's failing. I'm guessing that the server that is running hasn't been started standalone-full.xml and instead has used the default standalone.xml. I know you noted that it's started using standalone-full.xml in the IDE, but I don't think it's using that one.

          • 2. Re: Cannot obtain JMS ConnectionFactory
            Justin Bertram Master

            Here's the relevant code from Wildfly's "Hello World" JMS quickstart: https://github.com/wildfly/quickstart/blob/master/helloworld-jms/src/main/java/org/jboss/as/quickstarts/jms/HelloWorldJMSClient.java.  I'm not sure if this makes a difference, but the quickstart code doesn't set some of the JNDI properties you are setting.

            • 3. Re: Cannot obtain JMS ConnectionFactory
              George Berish Novice

              Hi Jaikiran and Justin,


              Thanks for you input.  And my apologies for the delay in responding, but Wildfly is killing me!


              I have no idea why, but I found that if I start WildFly using the Command Line (dos command window) JMS works as its supposed to.


              But if I allow Eclipse Luna to start WildFly it doesn't.


              Same code both times.

                 Main method run from Luna both times.

              One works. One doesn't.

              So its not the code.


              I tried to address that oddity in another post:


              So far no luck.

              So I've given up.

              Removed Wildfly as a server controlled by Eclipse.

              Now start Wildfly with "%JBOSS_HOME%/bin/standalone.bat -c standalone-full.xml.

              And my JMS problem disappeared.


              Don't know why.  And the other discussion went way beyond my depth so I gave up.



              • 4. Re: Cannot obtain JMS ConnectionFactory
                George Berish Novice

                Hi Justin,


                Just one final  thanks and note.


                It can't be the code, because when I start Wildfly manually the code works fine.  Please see above comment for reference to that problem.


                Wildfly just isn't really ready yet for anyone outside of its development cult I fear.



                • 5. Re: Cannot obtain JMS ConnectionFactory
                  Justin Bertram Master

                  I can't speak to your problem because I don't use Eclipse.  However, I can say it's easy to attach a debugger to a running Wildfly process and you won't be running Wildfly from Eclipse in production so it may not be best to launch Wildfly from Eclipse in the first place (IMO).


                  As far as Wildfly's readiness for anyone outside of its "development cult," I suppose I would disagree based on what you yourself said - your code works against Wildfly itself.  Eclipse isn't Wildfly and JBossTools isn't Wildfly so why blame Wildfly for what appears to be some kind of integration issue between Eclipse, JBossTools, and Wildfly when your code works against Wildfly itself?

                  • 6. Re: Cannot obtain JMS ConnectionFactory
                    George Berish Novice



                    Fair point.


                    Grin ... but ... since this morning, the Wildfly console decided I no longer had the credentials to us it.  "ACCESS DENIED". So now I'm off for a limited course in security management ... even though my only use for Wildfly it to try out applications written in Java ... in an environment where no one else has access.


                    But more seriously, If you try to do a search for the same problem on both Glassfish and Wildfly ... there really is no competition. 


                    Glassfish delivers a lot of understandable and useable info. Wildfly mostly returns stuff that I assume only makes sense to people whose only interest is in servers, Very little for people who develop things that need servicing.


                    I mean it took me no more than 20 minutes to remove the password from my local Glassfish.  Four days and four hours later, I can't find a single clear discussion of whether that is even possible with Wildfly.  And posting the question just returned much on why security is important, and how I need to "look at" how users and roles are utilized.  Zero on if, and if so, how, to just remove the  need for a password.  Grin ... and a few workarounds like allowing Foxfire to just remember it for me.


                    But I'm just venting.  I'm pretty sure I'll just return to Glassfish v4.


                    Thanks again for you insight and help.