[ https://issues.jboss.org/browse/WFLY-3211?page=com.atlassian.jira.plugin.... ] Eduardo Martins commented on WFLY-3211: --------------------------------------- 1) Seems java:app is fine, the app client has access to it as normal and works as expected in my tests. Seems the real issue comes from HornetQ, which uses, to lookup from jndi, a thread that doesn't have the thread local state (namespace context selector), which WildFly Naming uses to select to the specific java:app naming store in context. When that happens WildFly Naming exposes only the global namespaces, and that's why the java:global works. Here is a stack trace of HornetQ's jndi lookup, which may hint where this come from and how to solve: 17:07:41,758 WARN [org.jboss.as.naming] (default-threads - 2) jndi lookup java:app/jms/queue/queue2, selector = org.jboss.as.naming.service.DefaultNamespaceContextSelectorService$1@732311df: java.lang.Exception at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184) at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_45] at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_45] at org.hornetq.ra.HornetQRaUtils.lookup(HornetQRaUtils.java:179) [hornetq-ra-2.4.1.Final.jar:] at org.hornetq.ra.inflow.HornetQActivation.setupDestination(HornetQActivation.java:618) [hornetq-ra-2.4.1.Final.jar:] at org.hornetq.ra.inflow.HornetQActivation.setup(HornetQActivation.java:325) [hornetq-ra-2.4.1.Final.jar:] at org.hornetq.ra.inflow.HornetQActivation.handleFailure(HornetQActivation.java:743) [hornetq-ra-2.4.1.Final.jar:] at org.hornetq.ra.inflow.HornetQActivation$SetupActivation.run(HornetQActivation.java:798) [hornetq-ra-2.4.1.Final.jar:] at org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:219) at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33) at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:808) at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45) at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:828) at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45] at org.jboss.threads.JBossThread.run(JBossThread.java:122) 2) The other issue you noticed, the different behaviour when you include MessagingDefinitions.class in the ejb.jar, it is actually because you have the annotations in a class that is not container managed. EE.5.18.5: "A JMS Destination resource may also be defined using the JMSDestinationDefinition annotation on a container-managed class, such as a servlet or enterprise bean class." Seems WildFly follows this strictly, and when in the ejb jar I see the class annotations being parsed, added to EEModuleDescription's class descriptions, but then not processed further, thus the missing bindings. Oddly, it seems MessagingJMSDefinitionAnnotationParser behaves different for web and app clients modules, adding the binding configuration also to the module's bindings, and that's why the bindings are done in the app client scenario. Now If you add the JMSDestinationDefinitions to the MDBs instead, then the behaviour is the same as for the app client jar (you may need to force deployment order so ejb is processed before app client). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira