Can JMS topic subscribers (non-MDB) access EJB's in Wildfly 10/JavaEE 7?

[milspec]

Hi all,

We are migrating an application from jboss4 to wildfly 10.1

So far so good (though we've come across several snags I've logged earlier in this forum)

JMS Problem

We came across an issue  where a hand-coded (not Message Driven Bean or MDB) JMS Message Listener could not find the jndi entry for an EJB

Previously Encountered Thread Problem

This looked much like an earlier issue we encountered:   spawned threads could not find jndi entries for EJB's. We solved this particular problem by moving from "new Thread()" to the JavaEE-provided ManagedThreadFactory.

Back to JMS

So back to the jms issue.

Reviewing the code,  I don't see any obvious place to insert a jboss-provided class into the "onMessage" thread stack.  (see stack trace below)

The only thing I can think of: switching using an MDB for the message listener.

Questions

Do we have any other options other than using an MDB?

It's not a big effort to change it; I just wanted to be clear on the options.

thanks in advance,

Appendix A. Stack Trace

javax.naming.NameNotFoundException: java:app/pe-ejb/AuxFieldService!com.acme.shared.auxfields.service.ejb.AuxFieldServiceHome

    at org.jboss.as.naming.InitialContext$DefaultInitialContext.findContext(InitialContext.java:189)

    at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:233)

    at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)

    at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)

    at javax.naming.InitialContext.lookup(InitialContext.java:428)

    at javax.naming.InitialContext.lookup(InitialContext.java:428)

    at com.acme.util.factory.ejb.AbstractEJBServiceFactory.newEJBHome(AbstractEJBServiceFactory.java:146)

    at com.acme.util.factory.ejb.AbstractEJBServiceFactory.getEJBHome(AbstractEJBServiceFactory.java:129)

    at com.acme.util.factory.ejb.AbstractEJBServiceFactory.newService(AbstractEJBServiceFactory.java:104)

    at com.acme.util.factory.ejb.AbstractEJBServiceFactory.newService(AbstractEJBServiceFactory.java:89)

    at com.acme.shared.auxfields.service.AuxFieldServiceFactory.getService(AuxFieldServiceFactory.java:53)

    at com.acme.pe.msgboards.service.ejb.PostServiceEJB$PostIndexEntryWrapper.getIndexEntry(PostServiceEJB.java:3148)

    at com.acme.shared.indexer.service.IndexHelper.performAction(IndexHelper.java:534)

    at com.acme.shared.indexer.service.IndexJMSMessageListener.onMessage(IndexJMSMessageListener.java:101)

    at org.apache.activemq.artemis.jms.client.JMSMessageListenerWrapper.onMessage(JMSMessageListenerWrapper.java:93)

    at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1018)

    at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:48)

    at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1145)

    at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:103)

    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)

    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)

    at java.lang.Thread.run(Thread.java:785)

[jaikiran]

Is this message listener part of the same (.ear) application as the EJB which is being looked up?

[milspec]

Is this message listener part of the same (.ear) application as the EJB which is being looked up?

Yes.

The jms listener resides in a different jar (app.ear/lib/app-client.jar) than the ejb (app.ear/lib/app-ejb.jar). I think a) this setup is valid and  b) the problem is a 'jndi problem' rather than a 'classloading problem'

[jaikiran]

milspec wrote:

The jms listener resides in a different jar (app.ear/lib/app-client.jar) than the ejb (app.ear/lib/app-ejb.jar). I think a) this setup is valid and b) the problem is a 'jndi problem' rather than a 'classloading problem'

It's a valid packaging and the reason I asked wasn't related to classloading but the usage of java:app/ JNDI namespace which is only available for components belonging to the same (.ear) application as the target EJB. For other clients which aren't part of the same (.ear) application, the JNDI namespace to be used is java:global/. That was the context of my question.

Anyway, based on your answer, obviously, you can still use the java:app/ namespace. As long as this lookup isn't happening when the deployment is in progress, I actually expect this lookup to work from any thread (but I might be wrong and may be misremembering the implementation details around the naming project in WildFly).