Setting up JBoss Messaging integration tests

[rachmato]

Dear Messaging

I was asked by Ryan to incorporate targets into the JBAS testsuite for running Messaging against the existing JBossMQ integration tests. I'm running into some problems with this task, and need your advice.

So far, I have added a target (not yet committed) to testsuite/build.xml to:
(i) create a 'messaging' configuration
(ii) start up JBAS with that configuration
(iii) run the JBossMQ tests against JBAS
(iv) shut down JBAS
(v) delete the 'messaging' configuration

Setting up the 'messaging' configuration was based largely on mimicking the target release-admin.xml in the Messaging1.0.1 distribution, as well as replacing jboss-remoting.jar, jboss-serialization.jar, jboss-aop.jar and jboss-aspect-library.jar with the modified versions in the deploy directory. Some of the JBossMQ tests are passing without change, so I suspect that the test case execution classpath and configuration I have set up are close to being what they should be.

The problem i'm having is that a number of the JBossMQ test cases test implementation-dependent aspects of JBossMQ, which may or may not have a
counterpart in Messaging. For example, the test case CleanTopicRemovalTestCase:
- creates a topic
- publishes a message to the topic
- checks the state of the JBossMQ service MessageCache
- deletes the topic
- checks the state of the JBossMQ service MessageCache
- the expected result is that message cache count (after) = message cache count(before) -1

In order to produce a similar test case for Messaging, I would really need to know if a counterpart to MessageCache exists in Messaging, and whether that counterpart should exhibit the same behaviour. That question isn't easily answered, without looking in detail at the Messaging implementation and all the classes.

So, i'm really uncertain as to what I should do here. A number of the JBossMQ test cases pass without change. Some fail for fairly simple reasons (e.g. user not defined), and these are easily fixed. Others fail because of implementation dependencies, as in the example I described, and are not so easily fixed.

I'd like to ask your advice on this matter - for the short term goal of getting a subset of the integration tests up and running, what is the best approach to deciding which tests should be modified and retained and which discarded?

On an unrelated point, the test cases will need to be modified (e.g. instances of object names changed from jboss.mq:service=DestinationManager to jboss.messaging:service=ServicePeer, for example). Should I create a new directory under testsuite/src/main/org/jboss/test, say messaging, to contain the new copies of the tests?

Richard

[timfox]

Dear Messaging

I was asked by Ryan to incorporate targets into the JBAS testsuite for running Messaging against the existing JBossMQ integration tests. I'm running into some problems with this task, and need your advice.

So far, I have added a target (not yet committed) to testsuite/build.xml to:
(i) create a 'messaging' configuration
(ii) start up JBAS with that configuration
(iii) run the JBossMQ tests against JBAS
(iv) shut down JBAS
(v) delete the 'messaging' configuration

Setting up the 'messaging' configuration was based largely on mimicking the target release-admin.xml in the Messaging1.0.1 distribution, as well as replacing jboss-remoting.jar, jboss-serialization.jar, jboss-aop.jar and jboss-aspect-library.jar with the modified versions in the deploy directory. Some of the JBossMQ tests are passing without change, so I suspect that the test case execution classpath and configuration I have set up are close to being what they should be.

The problem i'm having is that a number of the JBossMQ test cases test implementation-dependent aspects of JBossMQ, which may or may not have a
counterpart in Messaging. For example, the test case CleanTopicRemovalTestCase:
- creates a topic
- publishes a message to the topic
- checks the state of the JBossMQ service MessageCache
- deletes the topic
- checks the state of the JBossMQ service MessageCache
- the expected result is that message cache count (after) = message cache count(before) -1

In order to produce a similar test case for Messaging, I would really need to know if a counterpart to MessageCache exists in Messaging, and whether that counterpart should exhibit the same behaviour. That question isn't easily answered, without looking in detail at the Messaging implementation and all the classes.

Understood. Probably the best thing here is to ask is specific questions as to whether alternatives exist and we should be able to answer

So, i'm really uncertain as to what I should do here. A number of the JBossMQ test cases pass without change. Some fail for fairly simple reasons (e.g. user not defined), and these are easily fixed. Others fail because of implementation dependencies, as in the example I described, and are not so easily fixed.

I'd like to ask your advice on this matter - for the short term goal of getting a subset of the integration tests up and running, what is the best approach to deciding which tests should be modified and retained and which discarded?

Best approach is probably to ask us and we should be able to answer :)

On an unrelated point, the test cases will need to be modified (e.g. instances of object names changed from jboss.mq:service=DestinationManager to jboss.messaging:service=ServicePeer, for example). Should I create a new directory under testsuite/src/main/org/jboss/test, say messaging, to contain the new copies of the tests?

Richard

Sounds like a good idea. We don't want to touch the MQ tests in any way.

[ovidiu.feodorov]

Setting up the 'messaging' configuration was based largely on mimicking the target release-admin.xml in the Messaging1.0.1 distribution, as well as replacing jboss-remoting.jar, jboss-serialization.jar, jboss-aop.jar and jboss-aspect-library.jar with the modified versions in the deploy directory. Some of the JBossMQ tests are passing without change, so I suspect that the test case execution classpath and configuration I have set up are close to being what they should be.

I would suggest using release-admin.xml directly That script is there to stay, as I don't see JBossMQ replaced by Messaging in the JBoss 4.0.x production releases in the near future. After clustering is done, yes, but not until the end of the year.

release-admin.xml assumes a clean "default" 4.x distribution (JBossMQ included) and builds a "messaging" distribution based on it. It does everything that is necessary to create a consistent Messaging-enabled JBoss instance without any effort on your part. We test the installation procedure during our release sequence, so it's guaranteed to work. It would be much easier for you just to call it from your ant script.

Also, keep in mind that we're working on separating the "jms" subtree from the 5.0 head so in the near future a messaging jar will be downloaded from the repository, along all other dependencies. However, this shouldn't affect you too much.

The problem i'm having is that a number of the JBossMQ test cases test implementation-dependent aspects of JBossMQ, which may or may not have a counterpart in Messaging.

Yes, we are aware of that.

First of all, no JBossMQ-specific tests should be changed. JBossMQ should be tested as before, since we're supporting it in production. It is true that the place of those implementation-specific tests is not in the integration testsuite, but since JBossMQ is in the maintenance mode, the simplest solution is to not change anything and leave them as they are.

In what Messaging is concerned, if a test is JBossMQ specific, ideally it should be duplicated and made JBossMQ-agnostic. I can help you with that on a case-by-case basis. Just send me the recipe to run the integration tests and a list of JBossMQ specific tests.

In the end, the integration tests should test Messaging's JMS compliance and compatibility with other JEMS components, not Messaging internals. That's the job of the functional test suite.

On an unrelated point, the test cases will need to be modified (e.g. instances of object names changed from jboss.mq:service=DestinationManager to jboss.messaging:service=ServicePeer, for example). Should I create a new directory under testsuite/src/main/org/jboss/test, say messaging, to contain the new copies of the tests?

This point is very much related to the previous paragraphs. JBossMQ test must remain unchanged. For Messaging integration tests, there should be no "jboss.messaging:service=ServerPeer", but only JMS-specified interaction.

[rachmato]

Tim, Ovidiu

Thank you for your very helpful comments and help in getting me started on this task!

Some replies:
1. Making use of release-admin.xml directly makes sense from the point of view of centralizing the code to create configurations. However, at present, we are pulling only pulling in jboss-messaging.jar into testsuite/thirdparty from repository.jboss.com, and don't have direct access to release-admin.xml. We are looking for a way to set up the configuration which makes life easy as well as being well-suited to the existing testsuite organization.

2. The JBAS build and testsuite makes use of a number of names for directories relating to JMS and the existing JBossMQ implementation:
trunk/messaging
trunk/testsuite/src/main/jms
trunk/testsuite/src/main/jmsra
trunk/testsuite/src/main/jbossmq
trunk/tetstsuite/src/resources/messaging
trunk/testsuite/src/resources/jbossmq

In incorporating these new Messaging tests, I tentatively chose the name messaging5 to be used as a basis for naming directories, files, and other related things.
trunk/testsuite/src/main/messaging5
trunk/testsuite/src/resources/messaging5
....
This would allow me to keep all the new Messaging artifacts separate from the existing JBossMQ and JMS atrifacts, as you suggested.
Is this name acceptable? Would another base name be preferable?

Richard

[timfox]

I don't think messaging5 is a good name since it ties us to the 5.x release.

Something like jbossmessaging sounds like a better choice to me.

[ovidiu.feodorov]

[e-mail] wrote:

1. Making use of release-admin.xml directly makes sense from the point of view of centralizing the code to create configurations. However, at present, we are pulling only pulling in jboss-messaging.jar into testsuite/thirdparty from repository.jboss.com, and don't have direct access to release-admin.xml. We are looking for a way to set up the configuration which makes life easy as well as being well-suited to the existing testsuite organization.

Ruel may have a say on this. The repository also provides a "resources" directory, that can be used for auxiliary scripts, I reckon. Quote from http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossBuild

Repository File Structure

...
repository.jboss.com\component name\version\lib
repository.jboss.com\component name\version\resources
...

resources - contains idl files, properties files, things of that nature

...

[e-mail] wrote:

2. The JBAS build and testsuite makes use of a number of names for directories relating to JMS and the existing JBossMQ implementation:
trunk/messaging
trunk/testsuite/src/main/jms
trunk/testsuite/src/main/jmsra
trunk/testsuite/src/main/jbossmq
trunk/tetstsuite/src/resources/messaging
trunk/testsuite/src/resources/jbossmq

"trunk/messaging" is a wrong name for JBossMQ related stuff to start with, I would change it to "jbossmq" everywhere it shows up in the source tree. Now with SVN is easy. This leaves messaging for us. As Tim said, messaging5 is bad.

[ruel.loehr]

The resource directory will indeed work for this.

[ovidiu.feodorov]

SO there's our solution, Richard.