Uploaded image for project: 'WildFly'
  1. WildFly
  2. WFLY-13949

JNDI lookup for JMS Queue failing

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Major
    • None
    • 20.0.1.Final
    • JMS
    • None
    • Hide

      The use case uses a package name of org.profsoftsvcs, but this can be replaced by whatever you like as long as the usage is consistent throughout.  Most of the directory names, etc., can be changed with the same proviso.  The use case is tailored for Linux, but could easily be modified for Windows.

      The attached file is a Maven-style project including a NetBeans profile.

      1) Define a new user, say "wflyplog".

      2) Unpack the attachment file into the home directory.  This should give a directory called "dpsrTest" with the Maven project underneath.

      3) Build the Maven project (mvn -f /home/wflyplog/data/dpsrTest/pom.xml -DskipTests=true --errors --errors clean install).  The POM includes a maven-assembly step which will create a JAR containing not only the test code but all needed WF classes as well from the boms.

      4) Unpack a virgin wildfly-20.0.1.Final.tar.gz into the home directory.

      5) Edit "/home/wflyplog/dpsrTest/target/classes/user.sh" and supply a valid password of your choice for userA.  Then execute "/home/wflyplog/dpsrTest/target/classes/"sh ./user.sh".  This will create userA with a group of "guest", as required by WF JMS.

      6) Bring up the WF server, e. g.

          cd w*l/bin
          sh standalone.sh -c standalone-full.xml >/tmp/out 2>/tmp/err &
          tail -f ~/tmp/out

      7) Execute "/home/wflyplog/dpsrTest/target/classes/"sh ./test.sh".  This will cause the exception.

      The application code is in /home/wflyplog/dpsrTest/src/main/java/org/profsoftsvcs/dpsrtest/Test.java.  It creates a default InitialContext from a supplied jndi.properties (found in /home/wflyplog/dpsrTest/target/classes) and tries to look up "jms/queue/DLQ".

       

      Show
      The use case uses a package name of org.profsoftsvcs, but this can be replaced by whatever you like as long as the usage is consistent throughout.  Most of the directory names, etc., can be changed with the same proviso.  The use case is tailored for Linux, but could easily be modified for Windows. The attached file is a Maven-style project including a NetBeans profile. 1) Define a new user, say "wflyplog". 2) Unpack the attachment file into the home directory.  This should give a directory called "dpsrTest" with the Maven project underneath. 3) Build the Maven project (mvn -f /home/wflyplog/data/dpsrTest/pom.xml -DskipTests=true --errors --errors clean install).  The POM includes a maven-assembly step which will create a JAR containing not only the test code but all needed WF classes as well from the boms. 4) Unpack a virgin wildfly-20.0.1.Final.tar.gz into the home directory. 5) Edit "/home/wflyplog/dpsrTest/target/classes/user.sh" and supply a valid password of your choice for userA.  Then execute "/home/wflyplog/dpsrTest/target/classes/"sh ./user.sh".  This will create userA with a group of "guest", as required by WF JMS. 6) Bring up the WF server, e. g.     cd w*l/bin     sh standalone.sh -c standalone-full.xml > /tmp/out 2> /tmp/err &     tail -f ~/tmp/out 7) Execute "/home/wflyplog/dpsrTest/target/classes/"sh ./test.sh".  This will cause the exception. The application code is in /home/wflyplog/dpsrTest/src/main/java/org/profsoftsvcs/dpsrtest/Test.java.  It creates a default InitialContext from a supplied jndi.properties (found in /home/wflyplog/dpsrTest/target/classes) and tries to look up "jms/queue/DLQ".  
    • Migration
    • Undefined
    • ---
    • ---

    Description

      I have a JMS app which has been running successfully under WF10 for some years.  I'm trying to migrate to WF20, but getting an error trying to look up the JMS Queue.  The JDK is OpenJDK 11.

      I've tried to make the reproducible case as simple as possible.  The server is unpacked from the downloaded tar.gz, and is not modified except to add a guest user for JMS (which is not needed for the reproducible case, since we never actually create a Connection).  The queue is the DLQ queue defined in the distribution.

      The error is a NameNotFoundException:

      Exception in thread "main" javax.naming.NameNotFoundException: jms/queue – service jboss.naming.context.java.jboss.exported.jms.queue
      at org.jboss.as.naming@20.0.1.Final//org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:106)
      at org.jboss.as.naming@20.0.1.Final//org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
      at org.jboss.as.naming@20.0.1.Final//org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
      at org.jboss.as.naming@20.0.1.Final//org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
      at org.wildfly.naming-client@1.0.13.Final//org.wildfly.naming.client.remote.RemoteServerTransport.handleLookup(RemoteServerTransport.java:203)
      at org.wildfly.naming-client@1.0.13.Final//org.wildfly.naming.client.remote.RemoteServerTransport$1.handleMessage(RemoteServerTransport.java:123)
      at org.jboss.remoting@5.0.18.Final//org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:430)
      at org.jboss.remoting@5.0.18.Final//org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:991)
      at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
      at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
      at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
      at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
      at java.base/java.lang.Thread.run(Thread.java:834)

      No matter what queue name I use, the lookup is failing on the string jms/queue rather than the expected jms/queue/DLQ.

      I fully expect that this is some stupid error on my part, something I'm looking at and just not seeing, because I know of others (albeit using Windows) who are using 20.0.1.Final for the full app without issue.  But I can't for the life of me see what it is.

      Tha actual full application looks up a ConnectionFactory of "jms/RemoteConnectionFactory" and creates Connections and Sessions before looking up the Queue name.  The lookup for the factory name works perfectly, as does the other stuff, but the lookup for the Queue name gets the same NameNotFoundException shown above.

      Attachments

        1. dpsrTest.tgz
          3 kB
        2. dpsrTest.tgz
          3 kB
        3. dpsrTest.tgz
          3 kB

        Activity

          People

            ehugonne1@redhat.com Emmanuel Hugonnet
            ftg314159 Francis Griffin (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: