[jboss-jira] [JBoss JIRA] (WFLY-3211) java:app resources can not be shared between ejb and appclient modules

[Eduardo Martins (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-3211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12959521#comment-12959521 ] 

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 at 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).
                
> java:app resources can not be shared between ejb and appclient modules
> ----------------------------------------------------------------------
>
>                 Key: WFLY-3211
>                 URL: https://issues.jboss.org/browse/WFLY-3211
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming
>    Affects Versions: 8.0.0.Final
>            Reporter: Jeff Mesnil
>            Assignee: Eduardo Martins
>
> use case:
> 1 ear composed of:
>   1 appclient module that defines 2 JMS queues (one in java:app, the other in java:global)
>   1 ejb modules with 2 MDBs (one listening to the java:app queue and the other to the java:global queue)
> When the ear is deployed:
> 1. the ejb module is deployed, the MDBs are created and wait for the creations of their respective queues (defined in the appclient module)
> 2. the appclient module is deployed, its 2 queues are deployed
> 3. the appclient main is run
> When the appclient uses the java:global queue, it looks it up, sends the message and the corresponding MDB receives it fine.
> When the appclient uses the java:app queue, it looks it up, sends the message but the corresponding MDB never receives it
> => the MDB was never deployed because it did not see the java:app queue deployed from the appclient module.
> Note that if I move the destination definitions to the ejb module, the MDBs are correctly activated but the appclient module is no longer deployed with errors:
> {noformat}
> [APPCLIENT-out] {"JBAS014771: Services with missing/unavailable dependencies" => [
> [APPCLIENT-out]     "jboss.naming.context.java.module.simple-jms-appclient-test.appclient.env.jms.queueInGlobal is missing [jboss.naming.context.java.global.jms.queu
> e.queue1]",
> [APPCLIENT-out]     "jboss.naming.context.java.module.simple-jms-appclient-test.appclient.env.jms.queueInApp is missing [jboss.naming.context.java.app.simple-jms-app
> client-test.jms.queue.queue2]"
> [APPCLIENT-out] ]}
> {noformat}
> Steps to reproduce:
> 1. fetch git branch https://github.com/jmesnil/wildfly/tree/jms_appclient
> 2. build WildFly
> 3. run ./integration-tests.sh -Dts.basic -Dtest=org.jboss.as.test.integration.ee.appclient.jms.basic.SimpleJMSApplicationClientTestCase -DnoWebProfile

--
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