We have noticed that a couple of weeks ago that JBossMQ disappeared from jboss-head. We believe that this is due to its impending replacement by JBoss Messaging in the 5.0 release. Up to now, the admin console was coded to work with JBossMQ. The short story is that we didn't want to chase a moving target (JBoss Messaging) while developing the admin console and knew we would have to, some time later, move to JBoss Messaging. Well, later is now.
At this point, the proposal is to clone the files related to JBossMQ and modify the cloned files to work with JBoss Messaging. Briefly, any directory named 'jms' will be cloned to a directory name 'messaging'. In addition, the home page will contain links to both the JBossMQ and JBoss Messaging functionality, with the later not working until all the changes are made. Once the changes are made, we can either:
1) leave it as is, thus providing management of both JBossMQ and JBoss Messaging, or
2) comment out the home page links to the JBossMQ management functions, which allows users who really need JBossMQ to uncomment the links to use that functionality, or
3) remove the JBossMQ functionality and support only JBoss Messaging.
I am leaning towards option #2, though can be easily swayed towards option #3. I would need a really good reason to support option #1.
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!!!