You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avro.apache.org by "Tom White (JIRA)" <ji...@apache.org> on 2012/09/11 13:06:11 UTC

[jira] [Created] (AVRO-1155) Stringable Date test in TestReflect fails if timezone doesn't match locale's default

Tom White created AVRO-1155:
-------------------------------

             Summary: Stringable Date test in TestReflect fails if timezone doesn't match locale's default
                 Key: AVRO-1155
                 URL: https://issues.apache.org/jira/browse/AVRO-1155
             Project: Avro
          Issue Type: Bug
          Components: java
            Reporter: Tom White
            Assignee: Tom White
             Fix For: 1.7.2


The problem is that java.util.Date's string contructor cannot reliably parse its toString() representation in some combinations of timezone and locale.

This started happening after AVRO-1146.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (AVRO-1155) Stringable Date test in TestReflect fails if timezone doesn't match locale's default

Posted by "Tom White (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/AVRO-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom White updated AVRO-1155:
----------------------------

      Resolution: Fixed
    Hadoop Flags: Reviewed
          Status: Resolved  (was: Patch Available)

I just committed this.
                
> Stringable Date test in TestReflect fails if timezone doesn't match locale's default
> ------------------------------------------------------------------------------------
>
>                 Key: AVRO-1155
>                 URL: https://issues.apache.org/jira/browse/AVRO-1155
>             Project: Avro
>          Issue Type: Bug
>          Components: java
>            Reporter: Tom White
>            Assignee: Tom White
>             Fix For: 1.7.2
>
>         Attachments: AVRO-1155.patch, AVRO-1155.patch
>
>
> The problem is that java.util.Date's string contructor cannot reliably parse its toString() representation in some combinations of timezone and locale.
> This started happening after AVRO-1146.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (AVRO-1155) Stringable Date test in TestReflect fails if timezone doesn't match locale's default

Posted by "Tom White (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/AVRO-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom White updated AVRO-1155:
----------------------------

    Attachment: AVRO-1155.patch

I agree. The fact that Date's String constructor and toString() methods are deprecated is another reason not to rely on them.

Here's a patch to remove Date from the list of built-in Stringables.
                
> Stringable Date test in TestReflect fails if timezone doesn't match locale's default
> ------------------------------------------------------------------------------------
>
>                 Key: AVRO-1155
>                 URL: https://issues.apache.org/jira/browse/AVRO-1155
>             Project: Avro
>          Issue Type: Bug
>          Components: java
>            Reporter: Tom White
>            Assignee: Tom White
>             Fix For: 1.7.2
>
>         Attachments: AVRO-1155.patch, AVRO-1155.patch
>
>
> The problem is that java.util.Date's string contructor cannot reliably parse its toString() representation in some combinations of timezone and locale.
> This started happening after AVRO-1146.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (AVRO-1155) Stringable Date test in TestReflect fails if timezone doesn't match locale's default

Posted by "Tom White (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/AVRO-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom White updated AVRO-1155:
----------------------------

    Status: Patch Available  (was: Open)
    
> Stringable Date test in TestReflect fails if timezone doesn't match locale's default
> ------------------------------------------------------------------------------------
>
>                 Key: AVRO-1155
>                 URL: https://issues.apache.org/jira/browse/AVRO-1155
>             Project: Avro
>          Issue Type: Bug
>          Components: java
>            Reporter: Tom White
>            Assignee: Tom White
>             Fix For: 1.7.2
>
>         Attachments: AVRO-1155.patch
>
>
> The problem is that java.util.Date's string contructor cannot reliably parse its toString() representation in some combinations of timezone and locale.
> This started happening after AVRO-1146.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (AVRO-1155) Stringable Date test in TestReflect fails if timezone doesn't match locale's default

Posted by "Doug Cutting (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/AVRO-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13453319#comment-13453319 ] 

Doug Cutting commented on AVRO-1155:
------------------------------------

+1
                
> Stringable Date test in TestReflect fails if timezone doesn't match locale's default
> ------------------------------------------------------------------------------------
>
>                 Key: AVRO-1155
>                 URL: https://issues.apache.org/jira/browse/AVRO-1155
>             Project: Avro
>          Issue Type: Bug
>          Components: java
>            Reporter: Tom White
>            Assignee: Tom White
>             Fix For: 1.7.2
>
>         Attachments: AVRO-1155.patch, AVRO-1155.patch
>
>
> The problem is that java.util.Date's string contructor cannot reliably parse its toString() representation in some combinations of timezone and locale.
> This started happening after AVRO-1146.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (AVRO-1155) Stringable Date test in TestReflect fails if timezone doesn't match locale's default

Posted by "Tom White (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/AVRO-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13452921#comment-13452921 ] 

Tom White commented on AVRO-1155:
---------------------------------

Here's the error I get when running with US locale settings and a UK timezone:

{noformat}
-------------------------------------------------------------------------------
Test set: org.apache.avro.reflect.TestReflect
-------------------------------------------------------------------------------
Tests run: 40, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.408 sec <<< FAILURE!
testStringables(org.apache.avro.reflect.TestReflect)  Time elapsed: 0.012 sec  <<< ERROR!
org.apache.avro.AvroRuntimeException: java.lang.reflect.InvocationTargetException
        at org.apache.avro.reflect.ReflectDatumReader.readString(ReflectDatumReader.java:129)
        at org.apache.avro.reflect.ReflectDatumReader.readString(ReflectDatumReader.java:114)
        at org.apache.avro.generic.GenericDatumReader.read(GenericDatumReader.java:150)
        at org.apache.avro.generic.GenericDatumReader.read(GenericDatumReader.java:135)
        at org.apache.avro.reflect.TestReflect.checkBinary(TestReflect.java:659)
        at org.apache.avro.reflect.TestReflect.checkBinary(TestReflect.java:668)
        at org.apache.avro.reflect.TestReflect.checkStringable(TestReflect.java:620)
        at org.apache.avro.reflect.TestReflect.testStringables(TestReflect.java:611)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
        at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
        at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
        at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
        at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
        at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
        at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
        at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
        at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
        at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
        at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
        at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
        at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
        at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:236)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:134)
        at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:113)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
        at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
        at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
        at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:103)
        at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
Caused by: java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
        at org.apache.avro.reflect.ReflectDatumReader.readString(ReflectDatumReader.java:121)
        ... 36 more
Caused by: java.lang.IllegalArgumentException
        at java.util.Date.parse(Date.java:598)
        at java.util.Date.<init>(Date.java:255)
        ... 41 more
{noformat}
                
> Stringable Date test in TestReflect fails if timezone doesn't match locale's default
> ------------------------------------------------------------------------------------
>
>                 Key: AVRO-1155
>                 URL: https://issues.apache.org/jira/browse/AVRO-1155
>             Project: Avro
>          Issue Type: Bug
>          Components: java
>            Reporter: Tom White
>            Assignee: Tom White
>             Fix For: 1.7.2
>
>
> The problem is that java.util.Date's string contructor cannot reliably parse its toString() representation in some combinations of timezone and locale.
> This started happening after AVRO-1146.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (AVRO-1155) Stringable Date test in TestReflect fails if timezone doesn't match locale's default

Posted by "Tom White (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/AVRO-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom White updated AVRO-1155:
----------------------------

    Attachment: AVRO-1155.patch

Here's a fix to use a stable string representation for the Date object.
                
> Stringable Date test in TestReflect fails if timezone doesn't match locale's default
> ------------------------------------------------------------------------------------
>
>                 Key: AVRO-1155
>                 URL: https://issues.apache.org/jira/browse/AVRO-1155
>             Project: Avro
>          Issue Type: Bug
>          Components: java
>            Reporter: Tom White
>            Assignee: Tom White
>             Fix For: 1.7.2
>
>         Attachments: AVRO-1155.patch
>
>
> The problem is that java.util.Date's string contructor cannot reliably parse its toString() representation in some combinations of timezone and locale.
> This started happening after AVRO-1146.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (AVRO-1155) Stringable Date test in TestReflect fails if timezone doesn't match locale's default

Posted by "Doug Cutting (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/AVRO-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13453204#comment-13453204 ] 

Doug Cutting commented on AVRO-1155:
------------------------------------

Fixing this with Date-specific code in ReflectDatumWriter feels wrong.  Rather perhaps Date is not a candidate for Stringable treatment after all, since it's toString() method does not always return a string that can be used to construct an equivalent Date instance.  If that's the case, then I think we should instead just remove Date from the default stringableClasses list in ReflectData.java and remove it from the tests in TestReflectData.java.  Thoughts?
                
> Stringable Date test in TestReflect fails if timezone doesn't match locale's default
> ------------------------------------------------------------------------------------
>
>                 Key: AVRO-1155
>                 URL: https://issues.apache.org/jira/browse/AVRO-1155
>             Project: Avro
>          Issue Type: Bug
>          Components: java
>            Reporter: Tom White
>            Assignee: Tom White
>             Fix For: 1.7.2
>
>         Attachments: AVRO-1155.patch
>
>
> The problem is that java.util.Date's string contructor cannot reliably parse its toString() representation in some combinations of timezone and locale.
> This started happening after AVRO-1146.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira