[jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - Re: MessageDriven tests in jboss-head

[adrian@jboss.org]

anonymous wrote : 
  | If you tell me what test you were working before, I will also be taking a look on it.
  | 

The restartJMS() test needs to work.
Currently it isn't even implemented


  | package org.jboss.test.messagedriven.test;
  | ...
  | public class JMSContainerInvokerQueueMessageDrivenUnitTestCase extends JMSContainerInvokerSimpleMessageDrivenUnitTest
  | ...  
  |    public void testRestartJMS() throws Exception
  |    {
  | 	  if (isJBossMessaging() == false)
  | 	  {
  | 	      Operation[] operations = new Operation[]
  | 	      {
  | 	         new SendMessageOperation(this, "1"),
  | 	         new CheckMessageSizeOperation(this, 1, 0),
  | 	         new CheckJMSDestinationOperation(this, 0, getDestination()),
  | 	         new CheckMessageIDOperation(this, 0, "1"),
  | 	         new StopOperation(this, persistenceManager),
  | 	         new StartOperation(this, persistenceManager),
  | 	         new SendMessageOperation(this, "2"),
  | 	         new CheckMessageSizeOperation(this, 2, 20000),
  | 	         new CheckJMSDestinationOperation(this, 0, getDestination()),
  | 	      };
  | 	      runTest(operations, defaultProps);
  | 	  }
  | 	  else
  | 	  {
  | 		  System.out.println("FIXME testRestartJMS for JBoss Messaging");
  | 	  }
  |    }
  | 

I'd like to fix it generically by changing the "persistenceManager" reference
to redeploy the DataSource, but that also doesn't work with JBoss Messaging.

The real fix is to have a JMSAdmin class for doing all the
deployQueue(), start/stopDelivery(), restartJMSServer()
in the testsuite. In fact, this nearly already exists in the Joram tests admin class.

anonymous wrote : 
  | Maybe... but we aways have more stuff to do than time available.
  | 

This attitude just makes more work for somebody else (like me)
who has to come along later and fix the problems.

Half a job now, usually means you have to do the twice the job in the long run ;-(

Currently the jboss-head testsuite is showing me that the jms api
at the jmx level is not backwards compatible with the older 4.2.x version
or the jbossmq version in 5.0.x.

One obvious example is the JMX name of the DLQ (and all the other hacks
in the messagedriven test)


  | 	  if (isJBossMessaging())
  | 	  {
  | 		   testQueue = ObjectNameFactory.create("jboss.messaging.destination:service=Queue,name=testQueue");
  | 		   testTopic = ObjectNameFactory.create("jboss.messaging.destination:service=Topic,name=testTopic");
  | 		   testDurableTopic = ObjectNameFactory.create("jboss.messaging.destination:service=Topic,name=testDurableTopic");
  | 		   dlqJMXDestination = ObjectNameFactory.create("jboss.messaging.destination:service=Queue,name=DLQ");
  | 		   destinations = "jbossmessaging/test-destinations-full-service.xml";
  | 	  }
  | 

This wouldn't be a problem if we had a better api, e.g. the manage jms
over jms I suggested over 2 years ago (which should really be in the jms spec :-).

The "long term" goal is to be able to run all the tests against any JMS provider,
otherwise how can we say JBoss works fine with WSMQ, etc.
let alone expect to support it.

You should have your own unit tests, the JBossAS testsuite should be generic,
it shouldn't include hacks like the above "c macro" :-)

Changing over JBossMessaging while still supporting jbossmq was an ideal
opportunity to resolve the problem, one that was sadly missed.

It's just another example where expediency leads to broken behaviour,
i.e. the testsuite is not fit for purpose.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4094160#4094160

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4094160