sunliyong / openrtb

Automatically exported from code.google.com/p/openrtb
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

Suspected windows build issue - failed test verifyPrettyPrinter(org.openrtb.common.json.AbstractJsonTranslatorTest) on Windows but OK on Linux #8

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Clone code on Windows XP or Windows 7 (I've tested on both)
2. mvn package

What is the expected output? What do you see instead?
The error message is: 
-------------------------------------------------------------------------------
Test set: org.openrtb.common.json.AbstractJsonTranslatorTest
-------------------------------------------------------------------------------
Tests run: 5, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.047 sec <<< 
FAILURE!
verifyPrettyPrinter(org.openrtb.common.json.AbstractJsonTranslatorTest)  Time 
elapsed: 0 sec  <<< FAILURE!
org.junit.ComparisonFailure: pretty printer didn't return the expected results 
expected:<{[
  "object" : {
    "value" : "subtype-value"
  },
  "long" : 1234,
  "string" : "parent-value"]
}> but was:<{[
  "object" : {
    "value" : "subtype-value"
  },
  "long" : 1234,
  "string" : "parent-value"
]
}>
    at org.junit.Assert.assertEquals(Assert.java:123)
    at org.openrtb.common.json.AbstractJsonTranslatorTest.verifyPrettyPrinter(AbstractJsonTranslatorTest.java:100)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

What version of the product are you using? On what operating system?
I have the tip (version 110) checked out on Windows XP and Windows 7

Please provide any additional information below.
The reason I think this is a Windows issue is that it works fine on my CentOS 
box (5.5). The other clue is that on my CentOS box the default encoding is UTF-8
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, 
i.e. build is platform dependent!
...whereas on windows its Cp1252
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered 
resources,i.e. build is platform dependent!

The offending code: 
    public void verifyPrettyPrinter() throws IOException {
        test.usePrettyPrinter();
        assertEquals("pretty printer didn't return the expected results", PRETTY_VALUE, test.toJSON(PARENT));

I've attached the logs

Original issue reported on code.google.com by Simon.Re...@gmail.com on 8 May 2011 at 1:20

Attachments:

GoogleCodeExporter commented 9 years ago
We may need to explicitly set the encoding to UTF-8

Original comment by willard....@gtempaccount.com on 8 May 2011 at 1:26

GoogleCodeExporter commented 9 years ago
I am observing the same issue on a Windows Vista machine, should I provide the 
platform encoding as part of pom.xml to fix this issue?

Original comment by rajesh.k...@gmail.com on 14 Jul 2011 at 7:26

GoogleCodeExporter commented 9 years ago
I added the following properties for the build to use UTF-8 in the root 
pom.xml, but the changes didn't make a difference though.

  <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <project.reporting.outputEncoding>${project.build.sourceEncoding}</project.reporting.outputEncoding>
        <file.encoding>${project.build.sourceEncoding}</file.encoding>
  </properties>          

Original comment by rajesh.k...@gmail.com on 14 Jul 2011 at 7:43

GoogleCodeExporter commented 9 years ago
So I figured it out. Its a line separator issue. On windows the line separator 
is \r\n, but on linux its just \n. 
I'll apply a patch in the next 24 hours. 

Original comment by Simon.Re...@gmail.com on 7 Aug 2011 at 2:57

GoogleCodeExporter commented 9 years ago

Original comment by Simon.Re...@gmail.com on 8 Aug 2011 at 2:06

GoogleCodeExporter commented 9 years ago
The JSON generator (Jackson) has a prettyprint option that is tested in  
verifyPrettyPrinter(org.openrtb.common.json.AbstractJsonTranslatorTest)
However, by default the generator uses class 
org.codehaus.jackson.impl.DefaultPrettyPrinter.Lf2SpacesIndenter
and the line separators that it generates are specific to the OS and therefore 
we need to check the line separators used in order to generate the correct 
PRETTY_VALUE to compare against

Original comment by Simon.Re...@gmail.com on 8 Aug 2011 at 2:20

GoogleCodeExporter commented 9 years ago
Works fine, with the new changes.

Original comment by rajesh.k...@gmail.com on 8 Aug 2011 at 8:52

GoogleCodeExporter commented 9 years ago

Original comment by Simon.Re...@gmail.com on 8 Aug 2011 at 11:38