The JBAS testsuite presently executes integration tests for the JMS provider JBossMQ, but not for the new JMS provider Messaging. This topic concerns changes to the testsuite to incorporate integration tests for Messaging.
Adding these tests to the testsuite involves the following steps:
1. create a new directory $JBAS/testsuite/src/main/org/jboss/test/jbossmessaging to hold the new integration tests and define an appropriate patternset
2. import the Messaging artifacts (e.g. jboss-messaging.jar) from repository.jboss.com into $JBAS/thirdparty (Messaging is no longer built within the JBAS build)
3. modify the tests.classpath to incorporate the new Messaging artifacts so that the new test classes are correctly compiled by the target compile-classes-only and make changes to $JBAS/testsuite/src/imports/test-jars.xml to create a suitable jar file jbossmessagingtests.jar
4. create a new messaging configuration
6. start up JBAS with the new configuration, call run-junit with the patternset to execute the tests and then shutdown the JBAS server
Steps 2 & 3 involve testsuite independently importing Messaging artifacts from respoitory.jboss.com into $JBAS/thirdparty. A mechanisms for doing this was incorporated into the testsuite/build.xml file in svn.repository.com/repos/jbossas/branches/Branch_4_0, making use of a new target createthirdparty in testsuite/build.xml and a new file build-thirdparty.xml.
The target checks if the thirdparty directory is up to date, and calls build-thirdparty.xml if it is not. It also generates a file thirdparty/testsuite-libraries.ent containing path definitions for the new thirdparty entries. This mechanism allows testsuite to independently make use of thirdparty libraries from the repository. However, if you need to add those libraries to the key testsuite classpaths, there is a problem, as the key classpaths (e.g. tests.classpath) get constructed before any targets are executed, including createthirdparty. What we propose is to force the classpaths to be built after createthirdparty has had a chance to execute by defining a target createclasspaths in which all the key testsuite claspath targets are built and which gets executed after createthirdparty. Dependencies will be added to ensure that the overall desired testsuite behaviour does not change. This will allow testsuite-libraries.ent to be included and used in a more flexible manner. This is one proposed change.
Step 4 involves creating a new messaging configuration. An existing ant script for doing this, release-admin.xml, is already present in the Messaging build. Rather than duplicate this code in the testsuite build, we propose to import release-admin.xml just as any other Messaging artifact, bring it into the $JBAS/testsuite/src/resources directory, and execute it to create the nmessaging configuration. This is a second proposed change.
We would like to incorporate these changes as follows:
1. Make the changes to allow testsuite to independently import and use thirdparty libraries. Commit the changes and monitor builds for a few days.
2. make the changes to allow release-admin.xml to be imported and executed. Commit the changes and monitor for a few days.
3. Continue adding tests cases for Messaging to $JBAS/testsuite/src/org/test/jboss/test/jbossmessaging
If there are no objections, we aim to incorporate the first set of changes late tomorrow (Friday, 1 September).
PS Please excuse the brevity - my first version of this posting, much more detailed and taking over an hour to write, was sent into the ether by the Preview button.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3968806#3968806
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3968806
Actually this gets more complex.
There are some situations where sending messages directly if the transaction is not enlisted in a global tx will give incorrect behaviour.
See this comment from MesagingXAResource:
| //If I commit/rollback the tx, then there is a short period of time between the AS (or whoever)
| //calling commit on the tx and calling start to enrolling the session in a new tx.
| //If the session has any listeners then in that period, messages can be received asychronously
| //but we want them to be received in the context of a tx, so we convert.
So we have to be very careful here.
AFAICT the only time when it would be valid to directly send messages using an XASession is if the session had never been enlisted in a global tx.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3968783#3968783
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3968783
Regarding the reference implementation, based on the amount of effort Sun put into the specification in the xa area, personally I doubt whether they have specifically considered this edge case, so any results obtained from there may just be an accident of implementation.
I think we should be driven by what our customers expect the behaviour to be , i.e. we should make it work like JBoss MQ.
I am interested in what the RI says, but only as a curiousity.
If we're really that bothered the place to get an answer (maybe) from the spec authors is the jms-interest mailing list at Sun.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3968779#3968779
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3968779