Uploaded image for project: 'Seam JMS'
  1. Seam JMS
  2. SEAMJMS-16

Event to JMS to Event mapping behavior

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Rejected
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      While working on seam jms, I've noted the following behavior.

      java.lang.IllegalStateException: Singleton not set for BaseClassLoader@3479404a

      {vfs:///apps/jboss/jboss-6.0.0.Final/server/all/conf/jboss-service.xml}

      at org.jboss.weld.integration.provider.JBossSingletonProvider$EarSingleton.get(JBossSingletonProvider.java:59) [:6.0.0.Final]
      at org.jboss.weld.Container.instance(Container.java:58) [:6.0.0.Final]
      at org.jboss.weld.resolution.ResolvableBuilder.checkQualifier(ResolvableBuilder.java:209) [:6.0.0.Final]
      at org.jboss.weld.resolution.ResolvableBuilder.addQualifier(ResolvableBuilder.java:174) [:6.0.0.Final]
      at org.jboss.weld.resolution.ResolvableBuilder.addQualifierIfAbsent(ResolvableBuilder.java:184) [:6.0.0.Final]
      at org.jboss.weld.manager.BeanManagerImpl.resolveObserverMethods(BeanManagerImpl.java:464) [:6.0.0.Final]
      at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:604) [:6.0.0.Final]
      at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:598) [:6.0.0.Final]
      at org.jboss.seam.jms.bridge.IngressMessageListener.onMessage(IngressMessageListener.java:45)
      at org.hornetq.jms.client.JMSMessageListenerWrapper.onMessage(JMSMessageListenerWrapper.java:91) [:6.0.0.Final]
      at org.hornetq.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:822) [:6.0.0.Final]
      at org.hornetq.core.client.impl.ClientConsumerImpl.access$100(ClientConsumerImpl.java:46) [:6.0.0.Final]
      at org.hornetq.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:940) [:6.0.0.Final]
      at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:100) [:6.0.0.Final]
      at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_22]
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_22]
      at java.lang.Thread.run(Thread.java:662) [:1.6.0_22]

      This exception occurs when trying to fire an event with the contents of a JMS message. The message listener in this case is instantiated from the portable extension and receives the bean manager as an argument in the constructor. I am able to get as far as reading the data from JMS, but when firing the second event the above exception occurs. I'm not certain that this is a Weld problem, but it seem slike a good place to start based on the packages shown.

        Gliffy Diagrams

          Activity

          Hide
          pmuir Pete Muir added a comment -

          Reopening, I don't understand what is spec required about this? Also, this is certainly fixable in JBoss AS, even if we have to do something complex to get there.

          Show
          pmuir Pete Muir added a comment - Reopening, I don't understand what is spec required about this? Also, this is certainly fixable in JBoss AS, even if we have to do something complex to get there.
          Hide
          meetoblivion John Ament added a comment -

          Realized last night (with help from Stuart Douglas) that this issue (with TCCL) was being cauesd by hornetq sending messages outside of the application. By passing in the context class loader from another bean, we can set the class loader within the on message method, then set it back in a finally block. This allows the body of the on message to be executed within the app's class loader, fixing any issues with bean resolution.

          Show
          meetoblivion John Ament added a comment - Realized last night (with help from Stuart Douglas) that this issue (with TCCL) was being cauesd by hornetq sending messages outside of the application. By passing in the context class loader from another bean, we can set the class loader within the on message method, then set it back in a finally block. This allows the body of the on message to be executed within the app's class loader, fixing any issues with bean resolution.
          Hide
          pmuir Pete Muir added a comment -

          John, I obviously failed to explain this well to you, as this is what I was getting at when we were chatting ;- Sorry about that!

          Show
          pmuir Pete Muir added a comment - John, I obviously failed to explain this well to you, as this is what I was getting at when we were chatting ;- Sorry about that!
          Hide
          pmuir Pete Muir added a comment -

          John, I obviously failed to explain this well to you, as this is what I was getting at when we were chatting ;- Sorry about that!

          Show
          pmuir Pete Muir added a comment - John, I obviously failed to explain this well to you, as this is what I was getting at when we were chatting ;- Sorry about that!
          Hide
          meetoblivion John Ament added a comment -

          Rejecting, as this was a development issue that was believed by the dev to be a weld problem but is really a CL issue.

          Show
          meetoblivion John Ament added a comment - Rejecting, as this was a development issue that was believed by the dev to be a weld problem but is really a CL issue.

            People

            • Assignee:
              Unassigned
              Reporter:
              meetoblivion John Ament
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development