Hide Forgot
Date of First Response: 2008-07-02 06:57:57 project_key: SOA Tracker issue for JBM test suite failures we see with SOA-P binaries. See linked issues.
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.