anonymous wrote : | 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. anonymous wrote : | 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. anonymous wrote : | 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. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3959705#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...