5 Replies Latest reply on Dec 6, 2007 8:47 PM by Aaron Walker

    NullPointerExecption when starting the Message Bridge

    Aaron Walker Newbie

      This issue is to do with the use of FactoryRef attribute from the JMSProviderLoader when looking up the ConnectionFactory in JNDI. It's actually valid not to provide one when create a JMSProviderLoader. Certain unnamed message providers don't have a single based class that implements both the Queue and Topic connection factories. As a work around I created two different JMSProviderLoaders and and bound the Topic or Queue connection factory to the FactoryRef attribute. This is not ideal really the bridge should get the QueueFactoryRef or TopicFactoryRef depending on the destination type.

      I can raise and JIRA for this and submit a patch if you want....


        • 3. Re: NullPointerExecption when starting the Message Bridge
          Aaron Walker Newbie

          I now getting this exception

          2007-12-07 12:20:42,534 WARN [org.jboss.jms.server.bridge.Bridge] Failed to send + acknowledge batch, closing JMS objects
          javax.jms.JMSException: Can only set JMSXGroupId, JMSXGroupSeq, JMSXDeliveryCount
           at org.jboss.jms.message.JBossMessage.checkProperty(JBossMessage.java:1102)
           at org.jboss.jms.message.JBossMessage.setObjectProperty(JBossMessage.java:916)
           at org.jboss.jms.message.JBossMessage.<init>(JBossMessage.java:365)
           at org.jboss.jms.message.JBossObjectMessage.<init>(JBossObjectMessage.java:94)
           at org.jboss.jms.client.container.ProducerAspect.handleSend(ProducerAspect.java:197)
           at org.jboss.aop.advice.org.jboss.jms.client.container.ProducerAspect39.invoke(ProducerAspect39.java)
           at org.jboss.jms.client.delegate.ClientProducerDelegate$send_3961598017717988886.invokeNext(ClientProducerDelegate$send_3961598017717988886.java)
           at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
           at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
           at org.jboss.jms.client.delegate.ClientProducerDelegate$send_3961598017717988886.invokeNext(ClientProducerDelegate$send_3961598017717988886.java)
           at org.jboss.jms.client.delegate.ClientProducerDelegate.send(ClientProducerDelegate.java)
           at org.jboss.jms.client.JBossMessageProducer.send(JBossMessageProducer.java:164)
           at org.jboss.jms.client.JBossMessageProducer.send(JBossMessageProducer.java:207)
           at org.jboss.jms.client.JBossMessageProducer.send(JBossMessageProducer.java:145)
           at org.jboss.jms.client.JBossMessageProducer.send(JBossMessageProducer.java:136)
           at org.jboss.jms.server.bridge.Bridge.sendBatch(Bridge.java:1200)
           at org.jboss.jms.server.bridge.Bridge.access$1700(Bridge.java:65)
           at org.jboss.jms.server.bridge.Bridge$SourceListener.onMessage(Bridge.java:1551)
           at com.ibm.mq.jms.MQMessageConsumer.receiveAsync(MQMessageConsumer.java:2969)
           at com.ibm.mq.jms.SessionAsyncHelper.run(SessionAsyncHelper.java:406)
           at java.lang.Thread.run(Thread.java:595)

          Had a look at the code and well the error message says it all. WSMQ is putting additional JMSX properties in the message header. What is the reasoning behind not allowing other options. Is it a spec compliance thing? It much easier to make changes to JBM is it possilbe to set some sort of spec compliance flag to allow non-compliant messages to flow through JBM



          • 4. Re: NullPointerExecption when starting the Message Bridge
            Tim Fox Master

            JMSX properties are reserved by the JMS spec.

            Provider defined properties are supposed to start with JMS_<vendor name>, so it seems like WSMQ is not following the spec (see JMS 1.1, 3.5.9, 3.5.10).

            We could I guess add a flag to relax this checking. Please feel free to add a feature request.

            • 5. Re: NullPointerExecption when starting the Message Bridge
              Aaron Walker Newbie

              Tim you know the spec far too well to be able to pull those sections back so quickly...:)

              All add a JIRA for this

              Where else other than the JBossMessage class would a check be needed?

              Is this meta-data at the ServerPeer level or more fine grained?