Wildfly 9.0.1 doesn't bound any of my JMS topics/queues

[moki]

When porting our application from Wildfly 8 to Wildfly 9.0.1, I discovered the application server doesn't bound any of the JMS queues and topics declared in the code.

In order to isolate and to reproduce the problem, I wrote a test code you can find at https://github.com/mmoqui/sandbox/tree/master/JEE7-Sandbox

In order to be sure the JMS topic declaration in the code is correct, I copy/past it from the following project https://github.com/wildfly/quickstart/blob/9.x/helloworld-mdb and I updated just the name of the topic.

With Widfly 8.2.1, the topic declared in the JEE7-Sandox code is correctly bound and I can send messages.

But with Wildfly 9.0.1, the topic isn't bound and an error is thrown when a message is sent. It seams Wildfly 9 isn't able to parse correctly the JMS annotations in the code. The topic is only bound if I define it explicitly in Wildfly 9 by CLI or through a -jms.xml descriptor.

In other side, what it is odd is that the topic and the queue declared in the helloworld-mdb project are correctly parsed and then bound by Widfly 9.0.1.

As I'm not sure it is a bug in Wildfly 9, I preferred to post my issue in this forum (before filing any bug issue in the tracker). What is wrong with my code (in JEE7-Sandbox)?

[jbertram]

I'm certainly no EE 7 expert, but my guess is that you're attempting to use injection in an object/component where injection is not supported.  I don't think injection is supported in arbitrary POJOs, but I could be wrong about that.

[moki]

Hum, I don't think so. The only unmanaged class I see is UserMessage and in this class I don't use dependency injection declaration but I use the BeanProvider class to access managed objects. Moreover, my code works fine in Wildfly 8 and not in WIldfly 9.

Beside that, when I import all my business classes into the HelloWorld-mdb example project (with the technical one BeanProvider and without my JMS-based code) and I invoke them in the existing MDBs, the example works fine.

No the problem lies elsewhere.

[mayerw01]

How can this issue be reproduced?

Which errors do you get in Wildfly9?

[moki]

The issue can be reproduced by taking the code at sandbox/JEE7-Sandbox at master · mmoqui/sandbox · GitHub and by compiling it and running it with Java 8 in Wildfly 9.0.1 in standalone-full configuration.

In the log of Wildfly, we can see no trace about any bound of the JMS topic defined in the code.

15:03:54,650 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-8) WFLYSRV0027: Starting deployment of "jee7-sandbox.war" (runtime-name: "jee7-sandbox.war")

15:03:54,965 INFO  [org.jboss.as.jpa] (MSC service thread 1-2) WFLYJPA0002: Read persistence.xml for jee7-sandbox

15:03:55,028 INFO  [org.jboss.as.jpa] (ServerService Thread Pool -- 14) WFLYJPA0010: Starting Persistence Unit (phase 1 of 2) Service 'jee7-sandbox.war#jee7-sandbox'

15:03:55,041 INFO  [org.hibernate.jpa.internal.util.LogHelper] (ServerService Thread Pool -- 14) HHH000204: Processing PersistenceUnitInfo [

  name: jee7-sandbox

  ...]

15:03:55,077 INFO  [org.jboss.weld.deployer] (MSC service thread 1-4) WFLYWELD0003: Processing weld deployment jee7-sandbox.war

15:03:55,129 INFO  [org.hibernate.Version] (ServerService Thread Pool -- 14) HHH000412: Hibernate Core {4.3.10.Final}

15:03:55,131 INFO  [org.hibernate.cfg.Environment] (ServerService Thread Pool -- 14) HHH000206: hibernate.properties not found

15:03:55,132 INFO  [org.hibernate.validator.internal.util.Version] (MSC service thread 1-4) HV000001: Hibernate Validator 5.1.3.Final

15:03:55,133 INFO  [org.hibernate.cfg.Environment] (ServerService Thread Pool -- 14) HHH000021: Bytecode provider name : javassist

15:03:55,471 INFO  [org.jboss.weld.deployer] (MSC service thread 1-2) WFLYWELD0006: Starting Services for CDI deployment: jee7-sandbox.war

15:03:55,515 INFO  [org.jboss.weld.Version] (MSC service thread 1-2) WELD-000900: 2.2.14 (Final)

15:03:55,567 INFO  [org.jboss.weld.deployer] (MSC service thread 1-2) WFLYWELD0009: Starting weld service for deployment jee7-sandbox.war

15:03:55,629 INFO  [org.jboss.as.ejb3] (MSC service thread 1-6) WFLYEJB0042: Started message driven bean 'UserMessageListener' with 'hornetq-ra.rar' resource adapter

...

In the nominal case, it should be have a trace the topic was found and bound before the starting of the MDB UserMessageListener like this:

INFO  [org.jboss.as.messaging] (MSC service thread 1-2) WFLYMSG0002: Bound messaging object to jndi name java:/topic/messages

and:

INFO  [org.hornetq.core.server] (ServerService Thread Pool -- 19) HQ221003: trying to deploy queue jms.topic.messages

As consequently when submitting a text from the web interface of the JEE7-Sandbox application an error is thrown. In the log of Wildfly, we can see that no name topic/messages was found (meaning then the topic defined in the code wasn't bound and then the annotations defining a such topic were not (correctly) parsed). The CreationException exception comes from the "NameNotFoundException: topic/messages" exception:

15:06:59,873 ERROR [io.undertow.request] (default task-5) UT005023: Exception handling request to /jee7-sandbox/services/messages: org.jboss.resteasy.spi.UnhandledException: javax.enterprise.inject.CreationException

  at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:76)

  at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:212)

  at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:149)

  at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:372)

  at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179)

  at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220)

  at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)

  at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)

  at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)

  at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86)

  at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)

  at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)

  at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)

  at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)

  at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)

  at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)

  at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)

  at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)

  at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)

  at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)

  at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)

  at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)

  at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)

  at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)

  at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)

  at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)

  at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)

  at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282)

  at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)

  at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)

  at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)

  at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)

  at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)

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

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

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

Caused by: javax.enterprise.inject.CreationException

  at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

  at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)

  at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)

  at java.lang.reflect.Constructor.newInstance(Constructor.java:422)

  at java.lang.Class.newInstance(Class.java:442)

  at org.jboss.weld.security.NewInstanceAction.run(NewInstanceAction.java:33)

  at java.security.AccessController.doPrivileged(Native Method)

  at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:40)

  at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:50)

  at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:54)

  at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:96)

  at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:375)

  at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:386)

  at org.jboss.weld.injection.producer.ResourceInjector$1.proceed(ResourceInjector.java:70)

  at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)

  at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:72)

  at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:121)

  at org.jboss.resteasy.cdi.JaxrsInjectionTarget.inject(JaxrsInjectionTarget.java:44)

  at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:159)

  at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96)

  at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101)

  at org.jboss.weld.bean.ContextualInstanceStrategy$CachingContextualInstanceStrategy.get(ContextualInstanceStrategy.java:178)

  at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50)

  at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:99)

  at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125)

  at org.silverpeas.sanbox.jee7sandbox.web.UserMessageResource$Proxy$_$$_WeldClientProxy.postNewUserMessage(Unknown Source)

  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

  at java.lang.reflect.Method.invoke(Method.java:497)

  at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137)

  at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:296)

  at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:250)

  at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:237)

  at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356)

  ... 32 more

Caused by: javax.naming.NameNotFoundException: topic/messages -- service jboss.naming.context.java.topic.messages

  at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:106)

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

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

  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:417)

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

  at org.jboss.as.weld.services.bootstrap.WeldResourceInjectionServices.resolveResource(WeldResourceInjectionServices.java:209)

  at org.jboss.as.weld.services.bootstrap.WeldResourceInjectionServices$1.createResource(WeldResourceInjectionServices.java:157)

  at org.jboss.weld.injection.AbstractResourceInjection.getResourceReference(AbstractResourceInjection.java:44)

  at org.jboss.weld.injection.AbstractResourceInjection.injectResourceReference(AbstractResourceInjection.java:53)

  at org.jboss.weld.util.Beans.injectEEFields(Beans.java:348)

  at org.jboss.weld.injection.producer.ResourceInjector$1.proceed(ResourceInjector.java:69)

  at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)

  at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:72)

  at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:121)

  at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:159)

  at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:69)

  at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101)

  at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50)

  at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:761)

  at org.jboss.weld.manager.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:861)

  at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:92)

  ... 56 more

[mayerw01]

This message usually indicates that your topic is not set up in WildFly.

You may create the topic via Administration console (Configuration -> Subsystems -> Messaging -> default -> destinations -> Topics -> Add)

[moki]

Yes, as I said in my first post, It works when the topic is created by CLI (or admin console) or by adding a -jms.xml descriptor into the project and in which the topic is defined.

But, according to JEE7 any JMS topics and queues can be defined by annotations (@JMSDestinationDefinitions and @JMSDestinationDefinition) in the code and then it is the responsible of the JEE application server to scan them in order to set up the topics and the queues. And I wish to use this feature for my applications.

This works fine in Wildfly 8 but no always in Wildfly 9: for some projects, the queues and topics can be reproducibly bound whereas for other projects queues and topic aren't reproducibly bound. And I don't know if it is an hidden issue in my code or from a vicious bug in Wildfly 9, knowing the use of the annotations seems correct for me. This is why I posted my problem here, in case an external glance can see an issue in the code that can explain why Wildfly 9 doesn't bound my topic whereas Wildfly 8 does (because Wildfly 9 is more constraining than Wildfly 8 in the JMS annotations declaration for example).

[ctomc]

well solution is simple.

jms destinations & related stuff needs to be on managed components otherwise it wont work.

so you can just add @Stateless to UserMessageSender class and it will work.

in quickstart it works as it is defined on servlet which is also managed component.

[moki]

Yes! It works once the bean is annotated with @Stateless, making it an EJB. My misconception was to think a CDI managed bean was enough to be taken into account by the JMS scanner of Wildfly (it was in Wildfly 8 but no more in Wildfly 9). I don't know yet if it is a regression or just a better compliance with the JEE specs.

Thank a lot

[jbertram]

So my original reply was correct?  You were attempting to use injection in an object/component that didn't support it?

[moki]

No. Dependency injection has nothing to do here. Dependency injection is managed by CDI and any beans are elective to CDI. The issue here comes from the JMS related annotations weren't scanned by Wildfly 9; it expects they are only on the pure JEE managed components (EJB, servlets, ..., those are special managed beans on top of CDI). The difference of behavior between Wildfly 8 with Wildfly 9 seems to be the annotations scanning was simplified under Wildfly 9 and by consequently JMS related annotations are only parsed when they belongs to a JEE component.

[jbertram]

No. Dependency injection has nothing to do here.

Whatever you say. 

From my reading of the thread and of your own comment here it seems to me that you were using an annotation in a component (i.e. a non-EE component) to inject a dependency that didn't support it.  Whether the issue comes down to annotation scanning or dependency injection in particular the result is the same.  I don't work much with these technologies so I've never differentiated between the actual annotation scanning and ultimate dependency injection although perhaps I should.

[moki]

it seems to me that you were using an annotation in a component (i.e. a non-EE component) to inject a dependency that didn't support it.

The annotations @JMSDestinationDefinitions and @JMSDestinationDefinition (about which I complained to be not scanned by Wildfly) aren't to inject dependencies but they are to define in my case a JMS topic (without the burden of a specific configuration in the application server). The @Resource and @Inject annotations used to inject dependencies (in my case the JMS topic and context) can be used in any beans that are elective to CDI; they can be a simple POJO as well as a JEE component.

[jbertram]

I see.  So the distinction is definition vs. injection.  You were using an annotation in a component (i.e. a non-EE component) to define a resource that didn't support it.  Thanks for the clarification.