On 13 Aug 2009, at 16:17, Mircea Markus wrote:
Hi there,
Here is a how things are with hudson tests:
- hudson user still cannot bind to UDP, so we're using TCP+TCPPING.
There are two tests that check that in the class named:
TcpMPingEnvironmentTest.
Can we disable this test by default, until we know that something has been done to allow UDP to work better on Hudson? It's just generating noise otherwise.
- I've found a workaround for the SingleStore test (one in which
coordinators were stopped): I've increased the TCPPING.port_range to 5
and that sorted the problem.
- S3 cache stores failures were fixed - Adrian if you can take a look
would be great
- other intermittent failures were fixed
Besides the 2 failures in TcpMPingEnvironmentTest, there are other 6:
- 3 failures in TableNameUniquenessTest - caused by xsd missing from
the path
- CacheManagerXmlConfigurationTest-
testNamedCacheXMLClashingNamesProgrammatic
- CacheManagerXmlConfigurationTest-testNamedCacheXML
- XmlFileParsingTest-testNamedCacheFileJaxb
All above 5 are failing with the same missing xsd error. Vladimir,
would it be possible for you to take a look at the 6 failure above?
I've mentioned these in a previous email, reiterating here for the record:
1. XSD should be generated before the test suite is run. Perhaps in the pre-test or post-compile phase.
2. The code should skip loading the schema if schema validation is disabled, following this algorithm:
validating = system property "infinispan.config.validate", defaults to true.
schema file = system property "infinispan.config.schema", defaults to schemas/infinispan-config-4.0.xsd
schema URL = system property "infinispan.config.schema.url" defaults to http://www.jboss.org/infinispan/infinispan-config-4.0.xsd
if (validating) {
1. try and load schema file from classpath
2. else, try and load schema file on file system
3. else, try and load from schema URL
4. else, throw an exception!
}
3. The unit test suite should *not* attempt to skip schema validation. This will, on one level, test schema validation code, and on another, ensure all sample cfg files we ship with are valid.
4. We should document the above system properties. Javadoc for Configuration could be one place, but also on the wiki.
Cheers
Manik
--