I have committed a couple of fixes to the ShapefileDataStoreTest cases
on trunk - both Eclisia and myself were failing when testing against a
JRE that did not have Chinese language installed.
The last failure I am seeing on trunk is as follows:
> Test set: org.geotools.wfs.WFSParsingTest
> -------------------------------------------------------------------------------
> Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 4.015
> sec <<< FAILURE!
> testParseGetFeature(org.geotools.wfs.WFSParsingTest) Time elapsed:
> 1.204 sec <<< FAILURE!
> junit.framework.AssertionFailedError: expected:<155> but was:<155>
> at junit.framework.Assert.fail(Assert.java:47)
> at junit.framework.Assert.failNotEquals(Assert.java:282)
> at junit.framework.Assert.assertEquals(Assert.java:64)
> at junit.framework.Assert.assertEquals(Assert.java:71)
> at
> org.geotools.wfs.WFSParsingTest.testParseGetFeature(WFSParsingTest.java:211)
Which comes down to:
> assertEquals(BigInteger.valueOf(155), f.getAttribute("intProperty"));
Stepping through with the debugger shows f.getAttribute("intProperty")
to be a String, and the binding for this type to also be String.class -
this is not what I expect from other datastore test cases but whatever.
This pattern repeats for each and every test, URI, Float and so on ...
Is anyone else experiencing this failure?
Jody
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
