Bug 778023

Link: Added: This issue depends JBMESSAGING-1287

Can we close this yet?

Can we rename to "run JBM test suite" and set version CONTINUING? 

Julian, can you monitor this?

Running current version soa-4.2.0.GA_CP03_CR5 I see org.jboss.test.messaging.jms.ManifestTest.testManifestEntries failing which as far as I can guess from the test log meand the messaging server doesn't return correct version but "UNKNOWN". This is SOA-P specific because EAP doesn't suffer from it. As well doesn't look like a bug in messaging itself.
http://hudson.qa.jboss.com/hudson/view/SOA-Release/job/soa-jbm/157/ - SOA-P result
http://hudson.qa.jboss.com/hudson/view/SOA-Release/job/soa-jbm/155/ - EAP result.

I see also 3 failures on windows but these are inherited from EAP (JBPAPP-1537) so I guess we need the fix in EAP.

Link: Added: This issue depends JBPAPP-1537

The failure of org.jboss.test.messaging.jms.ManifestTest.testManifestEntries is an odd one - see attached standalone test (copy it into the quickstarts dir to run it - the server returns this for 4.2 CP03 CR5:

runtest_soa547:
     [echo] Runs Test SOA-547
     [java] meta.getJMSMajorVersion()--> 1
     [java] meta.getJMSMinorVersion()--> 1
     [java] meta.getJMSProviderName()--> JBoss Messaging
     [java] meta.getJMSVersion()--> 1.1
     [java] meta.getProviderMajorVersion()--> 1
     [java] meta.getProviderMinorVersion()--> 4
     [java] meta.getProviderVersion()--> 1.4.0.SP3-CP04
     [java] meta.getJMSXPropertyNames()-->JMSXGroupID
     [java] meta.getJMSXPropertyNames()-->JMSXGroupSeq
     [java] meta.getJMSXPropertyNames()-->JMSXDeliveryCount

Attachment: Added: test_soa547.tar

Interesting. I wonder where JBM takes that information from. The difference between yours and JBM's test is that you are starting SOA-P and connect to it, where JBM test suite creates standalone messaging servers. I think it should be some difference between EAP and SOA-P because I run the tests against them in exactly the same manner. I'll try to check that.

The version is got from a file named VERSION which in tern got as a resource from the context classloader. jbossesb-rosetta.jar does contain a VERSION file but it is not what JBM needs. It happens to be taken first in this case. I see having the file called just VERSION too optimistic and would suggest changing to JBM_VERSION or whatever. I'll adapt my scripts anyways. 
As well your quick-start  looks nice to be included in the distro ;)

To conclude the only real problem by now is JBPAPP-1537.

In 4.2 CP03 CR5, the jboss-messaging.jar contains this VERSION file:

#
# This is an automatically generated file. DO NOT EDIT!
#
jboss.messaging.jmsVersion=1.1
jboss.messaging.jmsMajorVersion=1
jboss.messaging.jmsMinorVersion=1
jboss.messaging.jmsProviderName=JBoss Messaging
jboss.messaging.providerVersion=1.4.0.SP3-CP04
jboss.messaging.providerMajorVersion=1
jboss.messaging.providerMinorVersion=4
jboss.messaging.providerIncrementingVersion=26

I think that the test code also has to be changed - there are really 2 separate tests - (1) is the VERSION file correct and (2) does the server return the correct runtime information.

Yes, there is a file called VERSION in jbossesb-rosetta.jar.

I think that the test is enough to check that the JMSProviderName is "JBoss Messaging" because that means 1) the correct VERSION file is found and 2) server returns version. :)

Link: Added: This issue is related to JBMESSAGING-1478

This issue is not out of date. You can see JBMESSAGING-1478 where we have seen issues with the test suite on windows with the last SOA-P release.