-
1. Re: Wildfly 9.0.1 doesn't bound any of my JMS topics/queues
jbertram Aug 6, 2015 12:03 PM (in response to moki)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.
-
2. Re: Wildfly 9.0.1 doesn't bound any of my JMS topics/queues
moki Aug 7, 2015 4:28 AM (in response to jbertram)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.
-
3. Re: Wildfly 9.0.1 doesn't bound any of my JMS topics/queues
mayerw01 Aug 7, 2015 5:46 AM (in response to moki)How can this issue be reproduced?
Which errors do you get in Wildfly9?
-
4. Re: Wildfly 9.0.1 doesn't bound any of my JMS topics/queues
moki Aug 7, 2015 9:14 AM (in response to mayerw01)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
-
5. Re: Wildfly 9.0.1 doesn't bound any of my JMS topics/queues
mayerw01 Aug 7, 2015 10:30 AM (in response to moki)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)
-
6. Re: Wildfly 9.0.1 doesn't bound any of my JMS topics/queues
moki Aug 7, 2015 11:56 AM (in response to mayerw01)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).
-
7. Re: Wildfly 9.0.1 doesn't bound any of my JMS topics/queues
ctomc Aug 7, 2015 12:51 PM (in response to moki)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.
-
8. Re: Wildfly 9.0.1 doesn't bound any of my JMS topics/queues
moki Aug 7, 2015 1:24 PM (in response to ctomc)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
-
9. Re: Wildfly 9.0.1 doesn't bound any of my JMS topics/queues
jbertram Aug 8, 2015 11:02 PM (in response to moki)So my original reply was correct? You were attempting to use injection in an object/component that didn't support it?
-
10. Re: Wildfly 9.0.1 doesn't bound any of my JMS topics/queues
moki Aug 9, 2015 5:08 PM (in response to jbertram)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.
-
11. Re: Wildfly 9.0.1 doesn't bound any of my JMS topics/queues
jbertram Aug 9, 2015 8:36 PM (in response to moki)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.
-
12. Re: Wildfly 9.0.1 doesn't bound any of my JMS topics/queues
moki Aug 10, 2015 3:35 AM (in response to jbertram)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.
-
13. Re: Wildfly 9.0.1 doesn't bound any of my JMS topics/queues
jbertram Aug 10, 2015 8:59 AM (in response to moki)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.