org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase.unknown is actually failing because of OOM permgen

I needed to increase permgen from 768m through 1g to 1536m to make it pass. I hope it is using so much mem for a reason...

Link: Added: This issue depends SOA-1200

What is the status of this issue?

Will try this with ER5 build.

Need to construct a new no-auth patch for a SOA-P 5.0 server similar to:

/qa/tools/src/jboss/authpatch/jbossas-4.2.0-enableauth.patch

This patch was got from the EAP team at the time. I wonder if such patch can be generated by "diff -u <eap-noauth> <eap-auth>" and then applied to SOA-P.

Created the patch with diff -u as Alex suggested - hand edited to remove files not in SOA-P dist. (jmx-console-users.properties)

Attachment: Added: jbossas-5.0-enableauth.patch

* org.jboss.test.aop.test.TxLockUnitTestCase.testXml
java.lang.RuntimeException: TxLock didn't work.  2nd thread got there first.

* org.jboss.test.deployers.seam.test.SeamDvdExampleUnitTestCase.unknown
  The test timed out - will try to run locally to debug

* org.jboss.test.deployers.seam.test.SeamNumberguessExampleUnitTestCase.unknown
  The test timed out - will try to run locally to debug

* org.jboss.test.jca.test.TxConnectionManagerStressTestCase.unknown
  The test timed out - will try to run locally to debug

* org.jboss.test.profileservice.override.restart.test.ServiceBindingManagedObjectsTestCase(profileservice).testUpdatedStandardBindings
  The error is: expected:<25> but was:<27> - will try to run locally to debug

* org.jboss.test.profileservice.test.ProfileServiceUnitTestCase(profileservice).testDeploymentNames
  The error is: There are missing names: [deploy/jmx-remoting.sar/] - that .sar file is
  not deployed by the SOA-P servers. I just looked in an EAP distribution, and the .sar 
  is not deployed there either.

  This one fails for EAP too - same cause:  http://hudson.qa.jboss.com/hudson/view/EAP5/job/eap5-as-rhel5-x86-sun6/lastCompletedBuild/testReport/org.jboss.test.profileservice.test/ProfileServiceUnitTestCase%28profileservice%29/testDeploymentNames/

The remaining tests fail with scout classes not found - as we don't ship scout.jar with SOA-P

Most of the failures are class not found exceptions as SOA-P servers do not ship scout.jar:
./jboss-as/server/all/deploy/juddi-service.sar/scout.jar

# org.jboss.test.jaxr.scout.JaxrBaseTestCase(tests-scout-jaxr).testJaxrEssentials
# org.jboss.test.jaxr.scout.basic.JaxrJNDIConnectionTestCase(tests-scout-jaxr).testJaxrJNDIConnection
# org.jboss.test.jaxr.scout.publish.JaxrDeleteOrganizationTestCase(tests-scout-jaxr).testDeleteOrgs
# org.jboss.test.jaxr.scout.publish.JaxrDeleteOrganizationTestCase(tests-scout-jaxr).testJaxrEssentials
# org.jboss.test.jaxr.scout.publish.JaxrSaveOrganizationTestCase(tests-scout-jaxr).testSaveOrg
# org.jboss.test.jaxr.scout.publish.JaxrSaveOrganizationTestCase(tests-scout-jaxr).testJaxrEssentials
# org.jboss.test.jaxr.scout.publish.JaxrSaveServiceBindingTestCase(tests-scout-jaxr).testSaveServiceBinding
# org.jboss.test.jaxr.scout.publish.JaxrSaveServiceBindingTestCase(tests-scout-jaxr).testJaxrEssentials
# org.jboss.test.jaxr.scout.publish.infomodel.JaxrClassficationTestCase(tests-scout-jaxr).testClassificationOnConcepts
# org.jboss.test.jaxr.scout.publish.infomodel.JaxrClassficationTestCase(tests-scout-jaxr).testJaxrEssentials
# org.jboss.test.jaxr.scout.query.JaxrBusinessQueryTestCase(tests-scout-jaxr).testBusinessQuery
# org.jboss.test.jaxr.scout.query.JaxrBusinessQueryTestCase(tests-scout-jaxr).testJaxrEssentials

It looks like 

* org.jboss.test.deployers.seam.test.SeamDvdExampleUnitTestCase.unknown
* org.jboss.test.deployers.seam.test.SeamNumberguessExampleUnitTestCase.unknown

Are known issues with 5.0:   https://jira.jboss.org/jira/browse/JBPAPP-3235?focusedCommentId=12501386#action_12501386

org.jboss.test.aop.test.TxLockUnitTestCase.testXml - didn't fail on consequent test run

org.jboss.test.profileservice.override.restart.test.ServiceBindingManagedObjectsTestCase(profileservice).testUpdatedStandardBindings - this one has a hardcoded value (of managed components ?) of 25, this seems like just a change in SOA-P that affects the number of this value which in turn makes the test fail
test case is like:
ManagedComponent component = getServiceBindingManagerManagedComponent();
...
Map<String, ManagedProperty> properties = component.getProperties();
...
checkAddedBinding(properties, 25, 23456, offsets, hosts);
-> blows because 
assertEquals(bindingCount, refreshedElements.length);
--------------------^ is 25
--------------------------------------------------^ is properties.get("standardBindings").getValue().getElements() =27

I actually verified that in SOA-P there are two more services registered with the binding manager (admin console -> Service Binding Manager -> configuration) - EsbJuddiRMIPropertyService and EsbPropertyService so testUpdatedStandardBindings is failing because of the presence of these two compared to EAP. This is not a bug in SOA-P rather test case would need an improvement.

org.jboss.test.jca.test.TxConnectionManagerStressTestCase.unknown - passed with memory (-Xmx) upped with 1GB more
The two seam tests timed out again though so trying to run them separately to debug.

The two seam tests are failing and failure cause is indicated in the warning from server log below
org.jboss.test.deployers.seam.test.SeamDvdExampleUnitTestCase.unknown
org.jboss.test.deployers.seam.test.SeamNumberguessExampleUnitTestCase.unknown

03:42:35,740 WARN  [JpdlXmlReader] process parse warning: line 16: schema_reference.4: Failed to read schema document 'http://jboss.com/products/seam/pageflow-2.1.xsd', because 1) could not find the document; 2) the document could not be read; 3) the root element of the document is not <xsd:schema>.

http://jboss.com/products/seam/pageflow-2.1.xsd is referenced in configuration files and that resource is unavailable. With the resource present, tests are passing. The proper fix would be for the test suite to include this schema in the classpath rather than rely on jboss.com to serve it. Anyways, this is not a bug in SOA-P.

I think all failed tests have been investigated.

We're OK with regard to these tests - all failures are explained - let's keep the JIRA open until we can make the EAP tests configurable to handle SOA-P testing.