MessageDriven tests in jboss-head

[adrian.brock]

WRT: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=120986
I fixed up these tests so they are at least running.

Like I said originally, these tests should have been changed to use a pluggable
JMSAdmin class rather the hacks that are currently present. :-(

The test for restarting the JMS needs implementing, it is not an irrelevant test
like the comment in code stated.
Similary the problems with rebooting JBossMessaging I mentioned in different
thread a few months ago are still not fixed.

The topic tests for "deliveryActive" are currently failing. I think this is probably
a race condition (i.e. the subscription is not yet created when the message is sent?)
in the test but it needs confirming.

Finally, when I copy the test-destinations-full-service.xml to the deploy
directory and boot the server, I'm seeing "random" NPEs from the
PostOffice "getInstance" operation (it's not easy to reproduce - sorry no stacktrace).
Again, this looks like a race since if I touch the file after the server is fully booted, it
fixes itself (at least I've never seen the NPE with a fully booted server).

[clebert.suconic]

Adrian, what test are you specifically referring to?

we deploy XMLs in most of the destinations, as in some of them we have security attributes... so we need to mock what would happen in production.

Like I said originally, these tests should have been changed to use a pluggable
JMSAdmin class rather the hacks that are currently present. :-(

Maybe... but we aways have more stuff to do than time available. I just wanted to put the testsuite in a runnable state, besides the branch mania on jbossAS kind of sucked some of my time this quarter.

If this JMSAdmin thing becomes a priority we can revisit it.


Regarding the tests:

There are few tests failing because of some config issue.

For instance, if you start jboss-all and run the target "tests-jbossmessaging", the testsuite will run okay, but if you start from the main "test" target something is happening. I'm looking into that now.


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

[adrian.brock]

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.

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.

[clebert.suconic]

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.

It wouldn't work until yesterday...

I was having problems on jboss-as-4.2 and I fixed that. on the snapshot. what will make to 1.4.0.SP1 soon.

If you stop/start the datasource, JBossMessaging will be restarted fine.