We have noticed that a couple of weeks ago that JBossMQ disappeared from jboss-head.
It was my understanding from talking to the QA team that this was no longer the case and that JBossMQ had been restored as the default JMS provider in trunk.
Perhaps the QA team could tell us what to look for in the trunk checkout that will determine definitively which provider is currently being used.
JBossMQ was temporarily removed from head but change was reverted back couple of weeks back. If you look into build-distr.xml in trunk at https://svn.jboss.org/repos/jbossas/trunk/build/build-distr.xml, you will see that jbossmq.jar and corresponding client.jar is getting copied to all server config. Search for Messaging in this file. I hope this helps.
I don't think it has been completely decided.
What needs to be done to get JBossMQ back into default? Does this currently mean there is no JMS provider in the default config in /trunk?
JBoss Messaging will be the default in jboss5
Understood. Given there is currently no JMS provider in the default config in /trunk I was just talking about reinstating JBossMQ temporarily.
If you can test the admin console with the 'all' configuration from /trunk sufficiently that we can tag it, then I'm fine with leaving everything as is. Once we've got a tag, we can look at the work needed to migrate to JBoss Messaging.
The webtest reported a couple of failures running against the ?all? server configuration. Some of the failures can be resolved by specifying the server name at run time, however the failures in the JmsPageTest are a little harder to resolve! Basically the test was written expecting the changes made to the JBossMQ services (e.g. MessageCache, PersistenceManager, and StateManager) are hot deployable. However with the ?all? server, the configuration files for JBossMQ are deployed under the deploy-hasingleton/jms directory. When changes are made to the config files (e.g. hsqldb-jdbc2-service.xml, hsqldb-jdbc-state-service.xml), the new values are not reflected in the mbeans until the server is restarted. This caused the JmsPageTest to fail while verifying the changes.
The Admin Console?s readme file does indicate the webtest must run against the ?default? server. Looks like we?re telling the truth here!!!