[jira] [Commented] (THRIFT-1203) Java server returns JSON map items in the wrong order

[Ilya Maykov (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13047028#comment-13047028
 ] 

Ilya Maykov commented on THRIFT-1203:
-

Shouldn't we open a related ticket to make the test order-insensitive?

> Java server returns JSON map items in the wrong order
> -
>
> Key: THRIFT-1203
> URL: https://issues.apache.org/jira/browse/THRIFT-1203
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Compiler, Java - Library
>Affects Versions: 0.6, 0.7
>Reporter: Henrique Mendonca
>Priority: Minor
>  Labels: java, test, test-server
>
> This is a old bug I have forgotten to register.
> lib/js/test uses a Java server to run its unit tests, and by doing so I could 
> see that there is a small problem on the Java JSON map decoder.
> The unit test "testMap" should echo a map back to the client without 
> changing it, but it's messing up with the items order, e.g. {7=77, 8=88, 
> 9=99} returns {8=88, 9=99, 7=77}
> To run the server:
> thrift-trunk/lib/java$ ant compile-test
> thrift-trunk/lib/js/test$ ant testserver
> and go to http://localhost:8088/test/test.html
> Java test server console output:
> [java] Incoming content: 
> [1,"testMap",1,0,{"1":{"map":["i32","i32",3,{"7":77,"8":88,"9":99}]}}]
> [java] testMap({{8=88, 9=99, 7=77}})
> [java] Outgoing content: 
> [1,"testMap",2,0,{"0":{"map":["i32","i32",3,{"8":88,"9":99,"7":77}]}}]
> It's minor but it would be nice if any Java developer could have a look on it.
> Thanks a lot.
> ps.: the same works with a cpp server

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (THRIFT-1203) Java server returns JSON map items in the wrong order

[Roger Meier (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13047004#comment-13047004
 ] 

Roger Meier commented on THRIFT-1203:
-

Thanks all for clarification based on real facts and standards!
-Roger

> Java server returns JSON map items in the wrong order
> -
>
> Key: THRIFT-1203
> URL: https://issues.apache.org/jira/browse/THRIFT-1203
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Compiler, Java - Library
>Affects Versions: 0.6, 0.7
>Reporter: Henrique Mendonca
>Priority: Minor
>  Labels: java, test, test-server
>
> This is a old bug I have forgotten to register.
> lib/js/test uses a Java server to run its unit tests, and by doing so I could 
> see that there is a small problem on the Java JSON map decoder.
> The unit test "testMap" should echo a map back to the client without 
> changing it, but it's messing up with the items order, e.g. {7=77, 8=88, 
> 9=99} returns {8=88, 9=99, 7=77}
> To run the server:
> thrift-trunk/lib/java$ ant compile-test
> thrift-trunk/lib/js/test$ ant testserver
> and go to http://localhost:8088/test/test.html
> Java test server console output:
> [java] Incoming content: 
> [1,"testMap",1,0,{"1":{"map":["i32","i32",3,{"7":77,"8":88,"9":99}]}}]
> [java] testMap({{8=88, 9=99, 7=77}})
> [java] Outgoing content: 
> [1,"testMap",2,0,{"0":{"map":["i32","i32",3,{"8":88,"9":99,"7":77}]}}]
> It's minor but it would be nice if any Java developer could have a look on it.
> Thanks a lot.
> ps.: the same works with a cpp server

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (THRIFT-1203) Java server returns JSON map items in the wrong order

[T Jake Luciani (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

T Jake Luciani resolved THRIFT-1203.


Resolution: Won't Fix

> Java server returns JSON map items in the wrong order
> -
>
> Key: THRIFT-1203
> URL: https://issues.apache.org/jira/browse/THRIFT-1203
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Compiler, Java - Library
>Affects Versions: 0.6, 0.7
>Reporter: Henrique Mendonca
>Priority: Minor
>  Labels: java, test, test-server
>
> This is a old bug I have forgotten to register.
> lib/js/test uses a Java server to run its unit tests, and by doing so I could 
> see that there is a small problem on the Java JSON map decoder.
> The unit test "testMap" should echo a map back to the client without 
> changing it, but it's messing up with the items order, e.g. {7=77, 8=88, 
> 9=99} returns {8=88, 9=99, 7=77}
> To run the server:
> thrift-trunk/lib/java$ ant compile-test
> thrift-trunk/lib/js/test$ ant testserver
> and go to http://localhost:8088/test/test.html
> Java test server console output:
> [java] Incoming content: 
> [1,"testMap",1,0,{"1":{"map":["i32","i32",3,{"7":77,"8":88,"9":99}]}}]
> [java] testMap({{8=88, 9=99, 7=77}})
> [java] Outgoing content: 
> [1,"testMap",2,0,{"0":{"map":["i32","i32",3,{"8":88,"9":99,"7":77}]}}]
> It's minor but it would be nice if any Java developer could have a look on it.
> Thanks a lot.
> ps.: the same works with a cpp server

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (THRIFT-1203) Java server returns JSON map items in the wrong order

[Bill Dortch (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046960#comment-13046960
 ] 

Bill Dortch commented on THRIFT-1203:
-

A TreeMap would not preserve insertion order, or the order in which entries 
appeared in the original JSON, only the natural ordering of the keys, which may 
or may not be the same thing.  A LinkedHashMap preserves insertion order. 
However, there is no reason to do this. JSON objects, like most map-like data 
structures, are unordered.  As the definition at http://json.org states, "An 
object is an unordered set of name/value pairs." It is an error for a client, 
including a unit test client, to expect the entries of a JSON object to appear 
in a particular order, just as it would be an error to expect the presence or 
absence of whitespace, which is not significant.  A unit test based on 
comparison to a particular string representation of a JSON object is inherently 
flawed, as would be an application that did the same.

> Java server returns JSON map items in the wrong order
> -
>
> Key: THRIFT-1203
> URL: https://issues.apache.org/jira/browse/THRIFT-1203
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Compiler, Java - Library
>Affects Versions: 0.6, 0.7
>Reporter: Henrique Mendonca
>Priority: Minor
>  Labels: java, test, test-server
>
> This is a old bug I have forgotten to register.
> lib/js/test uses a Java server to run its unit tests, and by doing so I could 
> see that there is a small problem on the Java JSON map decoder.
> The unit test "testMap" should echo a map back to the client without 
> changing it, but it's messing up with the items order, e.g. {7=77, 8=88, 
> 9=99} returns {8=88, 9=99, 7=77}
> To run the server:
> thrift-trunk/lib/java$ ant compile-test
> thrift-trunk/lib/js/test$ ant testserver
> and go to http://localhost:8088/test/test.html
> Java test server console output:
> [java] Incoming content: 
> [1,"testMap",1,0,{"1":{"map":["i32","i32",3,{"7":77,"8":88,"9":99}]}}]
> [java] testMap({{8=88, 9=99, 7=77}})
> [java] Outgoing content: 
> [1,"testMap",2,0,{"0":{"map":["i32","i32",3,{"8":88,"9":99,"7":77}]}}]
> It's minor but it would be nice if any Java developer could have a look on it.
> Thanks a lot.
> ps.: the same works with a cpp server

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (THRIFT-1123) Patch to compile Thrift server and client for vc++ 9.0 and 10.0

[Patrick Larser (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046948#comment-13046948
 ] 

Patrick Larser commented on THRIFT-1123:


I tried using TNonblockingServer, following the instructions at: 
http://wiki.apache.org/thrift/ThriftUsageC%2B%2B.

Unfortunately, I am getting an error in server/TNonblockingServer.h:
libthrift\server\tnonblockingserver.h(33): fatal error C1083: Cannot open 
include file: 'unistd.h': No such file or directory

It looks like there's a dependance on a unix library. Has this been patched or 
is it a to-do for the windows conversion?

> Patch to compile Thrift server and client for vc++ 9.0 and 10.0
> ---
>
> Key: THRIFT-1123
> URL: https://issues.apache.org/jira/browse/THRIFT-1123
> Project: Thrift
>  Issue Type: Improvement
>  Components: C++ - Library
> Environment: Windows XP 32bit, vc++ 9.0, 10.0
>Reporter: Dragan Okiljevic
>Priority: Trivial
> Fix For: 0.7
>
> Attachments: 
> additional_thrift_cpp_visual_studio_2008_and_2010_endians_patch(concerning_ticket_1123_and_possibly_1031_patches).patch,
>  thrift_msvc_client_and_server.patch
>
>
> Extension of THRIFT-1031 patch published by James Dickson
> This patch is intended to provide Thrift C/C++ functionality on WIN32 
> platforms.
> The implementation is built on top of the patch "Patch to compile Thrift for 
> vc++ 9.0 and 10.0" by James Dickson published as THRIFT-1031. I just used 
> this code and ported more Thrieft C/C++ to WIN32 and added them to original 
> VC projects created in THRIFT-1031.
> I express my gratitude to Mr. Dickson as his post gave me the roadmap how to 
> do the additional changes, that I hope, would be useful for the rest of the 
> community too.
> Besides client capabilities enabled in THRIFT-1031, the library can now be 
> used for building Thrift servers and using concurrency features. The dir/file 
> structure from THRIFT-1031 and usage of Config.h header for providing support 
> for both WIN32 and *NIX remains.
> The implementation was tested briefly on MSVC2008, MSVC2010 and Ubuntu, 
> communicating between C/C++ clients and servers and Java clients and servers. 
> As the author needs all of this functionality for one of his projects, the 
> testing and debugging will continue.
> Revision 1086435 from March, 28, 2011. was used for development and creation 
> of patch, but it should be possible to apply it on current trunk revision as 
> long as no changes are made to patched files in trunk.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (THRIFT-1203) Java server returns JSON map items in the wrong order

[Bryan Duxbury (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046940#comment-13046940
 ] 

Bryan Duxbury commented on THRIFT-1203:
---

I think the ballpark is 3x longer for TreeMap vs HashMap.

However, even if they were the same performance, I'd be against the change. We 
would end up trying to guarantee that the ordering itself is the same between 
languages, which is, again, an exercise in helping a test pass. Not worth it.

> Java server returns JSON map items in the wrong order
> -
>
> Key: THRIFT-1203
> URL: https://issues.apache.org/jira/browse/THRIFT-1203
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Compiler, Java - Library
>Affects Versions: 0.6, 0.7
>Reporter: Henrique Mendonca
>Priority: Minor
>  Labels: java, test, test-server
>
> This is a old bug I have forgotten to register.
> lib/js/test uses a Java server to run its unit tests, and by doing so I could 
> see that there is a small problem on the Java JSON map decoder.
> The unit test "testMap" should echo a map back to the client without 
> changing it, but it's messing up with the items order, e.g. {7=77, 8=88, 
> 9=99} returns {8=88, 9=99, 7=77}
> To run the server:
> thrift-trunk/lib/java$ ant compile-test
> thrift-trunk/lib/js/test$ ant testserver
> and go to http://localhost:8088/test/test.html
> Java test server console output:
> [java] Incoming content: 
> [1,"testMap",1,0,{"1":{"map":["i32","i32",3,{"7":77,"8":88,"9":99}]}}]
> [java] testMap({{8=88, 9=99, 7=77}})
> [java] Outgoing content: 
> [1,"testMap",2,0,{"0":{"map":["i32","i32",3,{"8":88,"9":99,"7":77}]}}]
> It's minor but it would be nice if any Java developer could have a look on it.
> Thanks a lot.
> ps.: the same works with a cpp server

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (THRIFT-639) Timeouts Interrupting Read Can Leave Data in Read Queue, Corrupting Later Reads

[Bryan Duxbury (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bryan Duxbury closed THRIFT-639.


Resolution: Won't Fix

> Timeouts Interrupting Read Can Leave Data in Read Queue, Corrupting Later 
> Reads
> ---
>
> Key: THRIFT-639
> URL: https://issues.apache.org/jira/browse/THRIFT-639
> Project: Thrift
>  Issue Type: Bug
>  Components: Ruby - Library
>Affects Versions: 0.1, 0.2
>Reporter: Emily Leathers
>Priority: Minor
>
> When a Timeout interrupts a client that is reading a Thrift response, the 
> client may leave unread bytes in the read queue.  If this transport 
> instance/queue is reused in a later request, the extra bytes will corrupt 
> that later response.
> We're currently working around this by having the rescue blocks of our 
> TimeoutExceptions close the transport so that subsequent requests will have 
> to create a new, clean one.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (THRIFT-1203) Java server returns JSON map items in the wrong order

[T Jake Luciani (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046932#comment-13046932
 ] 

T Jake Luciani commented on THRIFT-1203:


If a parser is relying on the order of the map keys being the same then they 
are doing it wrong... maps are inherently unordered... I think making them 
strictly ordered is *less* portable across languages.

> Java server returns JSON map items in the wrong order
> -
>
> Key: THRIFT-1203
> URL: https://issues.apache.org/jira/browse/THRIFT-1203
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Compiler, Java - Library
>Affects Versions: 0.6, 0.7
>Reporter: Henrique Mendonca
>Priority: Minor
>  Labels: java, test, test-server
>
> This is a old bug I have forgotten to register.
> lib/js/test uses a Java server to run its unit tests, and by doing so I could 
> see that there is a small problem on the Java JSON map decoder.
> The unit test "testMap" should echo a map back to the client without 
> changing it, but it's messing up with the items order, e.g. {7=77, 8=88, 
> 9=99} returns {8=88, 9=99, 7=77}
> To run the server:
> thrift-trunk/lib/java$ ant compile-test
> thrift-trunk/lib/js/test$ ant testserver
> and go to http://localhost:8088/test/test.html
> Java test server console output:
> [java] Incoming content: 
> [1,"testMap",1,0,{"1":{"map":["i32","i32",3,{"7":77,"8":88,"9":99}]}}]
> [java] testMap({{8=88, 9=99, 7=77}})
> [java] Outgoing content: 
> [1,"testMap",2,0,{"0":{"map":["i32","i32",3,{"8":88,"9":99,"7":77}]}}]
> It's minor but it would be nice if any Java developer could have a look on it.
> Thanks a lot.
> ps.: the same works with a cpp server

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (THRIFT-1203) Java server returns JSON map items in the wrong order

[Roger Meier (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046930#comment-13046930
 ] 

Roger Meier commented on THRIFT-1203:
-

Yes, current implementation is order-insensitive.

http://wiki.apache.org/thrift/ThriftTypes mentions that Java uses HashMap

The spec at http://download.oracle.com/javase/1.4.2/docs/api/java/util/Map.html 
says
"The order of a map is defined as the order in which the iterators on the map's 
collection views return their elements. Some map implementations, like the 
TreeMap class, make specific *guarantees as to their order*; others, like the 
*HashMap* class, *do not*."

TreeMap vs. HashMap => What would it cost?

What about other languages?
Do they take care on the order of Map types?

> Java server returns JSON map items in the wrong order
> -
>
> Key: THRIFT-1203
> URL: https://issues.apache.org/jira/browse/THRIFT-1203
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Compiler, Java - Library
>Affects Versions: 0.6, 0.7
>Reporter: Henrique Mendonca
>Priority: Minor
>  Labels: java, test, test-server
>
> This is a old bug I have forgotten to register.
> lib/js/test uses a Java server to run its unit tests, and by doing so I could 
> see that there is a small problem on the Java JSON map decoder.
> The unit test "testMap" should echo a map back to the client without 
> changing it, but it's messing up with the items order, e.g. {7=77, 8=88, 
> 9=99} returns {8=88, 9=99, 7=77}
> To run the server:
> thrift-trunk/lib/java$ ant compile-test
> thrift-trunk/lib/js/test$ ant testserver
> and go to http://localhost:8088/test/test.html
> Java test server console output:
> [java] Incoming content: 
> [1,"testMap",1,0,{"1":{"map":["i32","i32",3,{"7":77,"8":88,"9":99}]}}]
> [java] testMap({{8=88, 9=99, 7=77}})
> [java] Outgoing content: 
> [1,"testMap",2,0,{"0":{"map":["i32","i32",3,{"8":88,"9":99,"7":77}]}}]
> It's minor but it would be nice if any Java developer could have a look on it.
> Thanks a lot.
> ps.: the same works with a cpp server

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (THRIFT-418) Don't do runtime sorting of struct fields

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046922#comment-13046922
 ] 

Hudson commented on THRIFT-418:
---

Integrated in Thrift #163 (See [https://builds.apache.org/job/Thrift/163/])
THRIFT-418. rb: Don't do runtime sorting of struct fields


Patch: Ilya Maykov

bryanduxbury : http://svn.apache.org/viewvc/?view=rev&rev=1134122
Files : 
* /thrift/trunk/lib/rb/lib/thrift/struct_union.rb
* /thrift/trunk/lib/rb/ext/thrift_native.c
* /thrift/trunk/lib/rb/ext/constants.h
* /thrift/trunk/compiler/cpp/src/generate/t_rb_generator.cc
* /thrift/trunk/lib/rb/ext/struct.c


> Don't do runtime sorting of struct fields
> -
>
> Key: THRIFT-418
> URL: https://issues.apache.org/jira/browse/THRIFT-418
> Project: Thrift
>  Issue Type: Improvement
>  Components: Ruby - Compiler, Ruby - Library
>Affects Versions: 0.1
>Reporter: Bryan Duxbury
>Assignee: Ilya Maykov
>Priority: Minor
> Fix For: 0.7
>
> Attachments: THRIFT-418-avoid-runtime-sorting-of-struct-fields.patch
>
>
> Currently the ruby struct code sorts the field ids of each struct every time 
> it is serialized, which is an unnecessary drag on performance. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (THRIFT-639) Timeouts Interrupting Read Can Leave Data in Read Queue, Corrupting Later Reads

[Ilya Maykov (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046915#comment-13046915
 ] 

Ilya Maykov commented on THRIFT-639:


I guess what I'm saying is, I don't think this is a bug, this behavior is by 
design. Right?

> Timeouts Interrupting Read Can Leave Data in Read Queue, Corrupting Later 
> Reads
> ---
>
> Key: THRIFT-639
> URL: https://issues.apache.org/jira/browse/THRIFT-639
> Project: Thrift
>  Issue Type: Bug
>  Components: Ruby - Library
>Affects Versions: 0.1, 0.2
>Reporter: Emily Leathers
>Priority: Minor
>
> When a Timeout interrupts a client that is reading a Thrift response, the 
> client may leave unread bytes in the read queue.  If this transport 
> instance/queue is reused in a later request, the extra bytes will corrupt 
> that later response.
> We're currently working around this by having the rescue blocks of our 
> TimeoutExceptions close the transport so that subsequent requests will have 
> to create a new, clean one.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (THRIFT-639) Timeouts Interrupting Read Can Leave Data in Read Queue, Corrupting Later Reads

[Ilya Maykov (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046914#comment-13046914
 ] 

Ilya Maykov commented on THRIFT-639:


I think you're supposed to throw away your connection/transport and re-create 
them when you get an error (and timeouts are a kind of error), because an error 
can be raised at any time and leave your connection/transport in an undefined 
state. At least, that's what Twitter's thrift_client gem (higher-level client 
on top of Thrift) does and it works pretty well in my experience.

> Timeouts Interrupting Read Can Leave Data in Read Queue, Corrupting Later 
> Reads
> ---
>
> Key: THRIFT-639
> URL: https://issues.apache.org/jira/browse/THRIFT-639
> Project: Thrift
>  Issue Type: Bug
>  Components: Ruby - Library
>Affects Versions: 0.1, 0.2
>Reporter: Emily Leathers
>Priority: Minor
>
> When a Timeout interrupts a client that is reading a Thrift response, the 
> client may leave unread bytes in the read queue.  If this transport 
> instance/queue is reused in a later request, the extra bytes will corrupt 
> that later response.
> We're currently working around this by having the rescue blocks of our 
> TimeoutExceptions close the transport so that subsequent requests will have 
> to create a new, clean one.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (THRIFT-1203) Java server returns JSON map items in the wrong order

[Bryan Duxbury (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046892#comment-13046892
 ] 

Bryan Duxbury commented on THRIFT-1203:
---

Maps don't have ordering. When you are comparing the results, this can be 
annoying, but it's not incorrect. Furthermore, making them ordered identically 
has a nonzero cost, so I don't think we should do it.

I think we should close this ticket "won't fix", or we should rename it to 
focus on changing the test itself to be order-insensitive.

> Java server returns JSON map items in the wrong order
> -
>
> Key: THRIFT-1203
> URL: https://issues.apache.org/jira/browse/THRIFT-1203
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Compiler, Java - Library
>Affects Versions: 0.6, 0.7
>Reporter: Henrique Mendonca
>Priority: Minor
>  Labels: java, test, test-server
>
> This is a old bug I have forgotten to register.
> lib/js/test uses a Java server to run its unit tests, and by doing so I could 
> see that there is a small problem on the Java JSON map decoder.
> The unit test "testMap" should echo a map back to the client without 
> changing it, but it's messing up with the items order, e.g. {7=77, 8=88, 
> 9=99} returns {8=88, 9=99, 7=77}
> To run the server:
> thrift-trunk/lib/java$ ant compile-test
> thrift-trunk/lib/js/test$ ant testserver
> and go to http://localhost:8088/test/test.html
> Java test server console output:
> [java] Incoming content: 
> [1,"testMap",1,0,{"1":{"map":["i32","i32",3,{"7":77,"8":88,"9":99}]}}]
> [java] testMap({{8=88, 9=99, 7=77}})
> [java] Outgoing content: 
> [1,"testMap",2,0,{"0":{"map":["i32","i32",3,{"8":88,"9":99,"7":77}]}}]
> It's minor but it would be nice if any Java developer could have a look on it.
> Thanks a lot.
> ps.: the same works with a cpp server

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (THRIFT-418) Don't do runtime sorting of struct fields

[Bryan Duxbury (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bryan Duxbury closed THRIFT-418.


   Resolution: Fixed
Fix Version/s: 0.7
 Assignee: Ilya Maykov

I just committed this patch to trunk. Thanks, Ilya!

> Don't do runtime sorting of struct fields
> -
>
> Key: THRIFT-418
> URL: https://issues.apache.org/jira/browse/THRIFT-418
> Project: Thrift
>  Issue Type: Improvement
>  Components: Ruby - Compiler, Ruby - Library
>Affects Versions: 0.1
>Reporter: Bryan Duxbury
>Assignee: Ilya Maykov
>Priority: Minor
> Fix For: 0.7
>
> Attachments: THRIFT-418-avoid-runtime-sorting-of-struct-fields.patch
>
>
> Currently the ruby struct code sorts the field ids of each struct every time 
> it is serialized, which is an unnecessary drag on performance. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (THRIFT-1191) Erlang binding throws during skipping fields of composite type (maps, lists, structs, sets)

[Bryan Duxbury (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046882#comment-13046882
 ] 

Bryan Duxbury commented on THRIFT-1191:
---

I have to say, I don't really understand what's happening in this patch. Could 
you supply a test, or could someone else have a look at sign off?

> Erlang binding throws during skipping fields of composite type (maps, lists, 
> structs, sets)
> ---
>
> Key: THRIFT-1191
> URL: https://issues.apache.org/jira/browse/THRIFT-1191
> Project: Thrift
>  Issue Type: Bug
>  Components: Erlang - Library
>Reporter: Anatoly Kanivetsky
> Attachments: THRIFT-1191.patch
>
>
> Erlang binding throws during skipping fields of composite type (maps, lists, 
> structs, sets)
> Here's the pull request with this fix:
> https://github.com/apache/thrift/pull/3 here is the patch
> Here's the fix only:
> https://github.com/chaos-ad/thrift/commit/d70576209ae01f7ae56a1afccc1210d120b0ecde

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Jenkins build is back to normal : Thrift #162

[Apache Jenkins Server]

See 

[jira] [Commented] (THRIFT-1200) JS compiler generates code that clobbers existing namespaces

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-1200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046871#comment-13046871
 ] 

Hudson commented on THRIFT-1200:


Integrated in Thrift #162 (See [https://builds.apache.org/job/Thrift/162/])
THRIFT-1200 js: JS compiler generates code that clobbers existing namespaces
fix broken build(jslint) introduced with original patch

roger : http://svn.apache.org/viewvc/?view=rev&rev=1134093
Files : 
* /thrift/trunk/compiler/cpp/src/generate/t_js_generator.cc


> JS compiler generates code that clobbers existing namespaces
> 
>
> Key: THRIFT-1200
> URL: https://issues.apache.org/jira/browse/THRIFT-1200
> Project: Thrift
>  Issue Type: Bug
>  Components: JavaScript - Compiler
>Affects Versions: 0.6.1
> Environment: all
>Reporter: Ilya Maykov
>Assignee: Ilya Maykov
> Fix For: 0.7
>
> Attachments: THRIFT-1200-js-namespace-fix.txt
>
>
> The JavaScript compiler currently generates code that will clobber an 
> already-existing namespace. It should check if the namespace exists before 
> initializing it to {}. Example code pre-patch, assuming the .thrift file has 
> the declaration {{namespace js CompanyName.ModuleName}}:
> {code:JavaScript}
> var CompanyName = {};
> CompanyName.ModuleName = {}
> {code}
> Becomes this after patch:
> {code:JavaScript}
> if (typeof CompanyName === 'undefined') CompanyName = {};
> if (typeof CompanyName.ModuleName === 'undefined') CompanyName.ModuleName = 
> {};
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (THRIFT-1102) typo in configure.ac: "==" operator in 'test' (instead of"'=")

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-1102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046872#comment-13046872
 ] 

Hudson commented on THRIFT-1102:


Integrated in Thrift #162 (See [https://builds.apache.org/job/Thrift/162/])


> typo in configure.ac: "==" operator in 'test' (instead of"'=")
> --
>
> Key: THRIFT-1102
> URL: https://issues.apache.org/jira/browse/THRIFT-1102
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process
>Affects Versions: 0.6
>Reporter: Sergey Skvortsov
>Assignee: Jake Farrell
> Fix For: 0.7
>
>   Original Estimate: 20m
>  Remaining Estimate: 20m
>
> While:
> ./configure --with-cpp
> command "test" returns false because of incorrect operator "==" and as result 
> "cpp" library do not built.
> Patch:
> --- configure.ac.orig 2011-03-20 21:26:41.0 +
> +++ configure.ac  2011-03-20 21:26:57.0 +
> @@ -85,7 +85,7 @@
>  have_cpp=no
>  if test "$with_cpp" = "yes";  then
>AX_BOOST_BASE([1.33.1])
> -  if test "x$succeeded" == "xyes" ; then
> +  if test "x$succeeded" = "xyes" ; then
>  have_cpp="yes"
>fi
>  

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (THRIFT-1181) AS3 compiler generates incorrect code for setting default values in constructor

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046869#comment-13046869
 ] 

Hudson commented on THRIFT-1181:


Integrated in Thrift #162 (See [https://builds.apache.org/job/Thrift/162/])


> AS3 compiler generates incorrect code for setting default values in 
> constructor
> ---
>
> Key: THRIFT-1181
> URL: https://issues.apache.org/jira/browse/THRIFT-1181
> Project: Thrift
>  Issue Type: Bug
>  Components: AS3 - Compiler
>Affects Versions: 0.6, 0.6.1, 0.7
> Environment: Mac OS X 10.6.7
>Reporter: Ethan Urie
>Assignee: Ethan Urie
>Priority: Minor
> Fix For: 0.7
>
> Attachments: THRIFT-1181_correct_default_value_syntax.patch
>
>
> If you create a thrift struct and set a field to have a default value, the 
> compiler puts the code to set that default value in the constructor of the 
> generated class. When it does this, it adds {{:Type}} to the right of the 
> variable, e.g., {{this.count:int = 0;}}. The generated statement isn't 
> correct syntax and fails to compile. The correct syntax would simply be 
> {{this.count = 0;}}.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (THRIFT-1180) AS3 compiler generates uncompilable code for binary types.

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-1180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046870#comment-13046870
 ] 

Hudson commented on THRIFT-1180:


Integrated in Thrift #162 (See [https://builds.apache.org/job/Thrift/162/])


> AS3 compiler generates uncompilable code for binary types.
> --
>
> Key: THRIFT-1180
> URL: https://issues.apache.org/jira/browse/THRIFT-1180
> Project: Thrift
>  Issue Type: Bug
>  Components: AS3 - Compiler
>Affects Versions: 0.5, 0.6, 0.6.1, 0.7
> Environment: Mac OS X 10.6.7 
>Reporter: Ethan Urie
>Assignee: Ethan Urie
>Priority: Minor
> Fix For: 0.7
>
> Attachments: THRIFT-1180_use_ByteArray_for_binary_types.patch
>
>
> When a thrift definition file includes a field of type {{binary}} the 
> generated code uses {{byte[]}} which is not valid AS3 (there's no byte 
> primitive). AS3 does provide the ByteArray class which would fix this issue.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (THRIFT-1140) Framed Transport Client using C (Glib) Library hangs when connecting to Ruby Server

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046868#comment-13046868
 ] 

Hudson commented on THRIFT-1140:


Integrated in Thrift #162 (See [https://builds.apache.org/job/Thrift/162/])


> Framed Transport Client using C (Glib) Library hangs when connecting to Ruby 
> Server
> ---
>
> Key: THRIFT-1140
> URL: https://issues.apache.org/jira/browse/THRIFT-1140
> Project: Thrift
>  Issue Type: Bug
>  Components: C glib - Library
> Environment: Debian 6.0, 64-bit
>Reporter: Lukas Fittl
>Assignee: Lukas Fittl
> Fix For: 0.7
>
> Attachments: thrift-1140.patch
>
>
> When using the C (Glib) library to connect using the framed transport and 
> binary protocol to connect to a Ruby-based server, the connection just hangs 
> during the write phase.
> This is due to a too big size being set in the Thrift header, so the server 
> waits for 4 bytes more than are actually being sent.
> The same issue happens the other way around, when the server sends a 
> response, but the client thinks it needs 4 more bytes of data.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (THRIFT-1199) Union structs should have generated methods to test whether a specific field is currently set

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-1199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046866#comment-13046866
 ] 

Hudson commented on THRIFT-1199:


Integrated in Thrift #162 (See [https://builds.apache.org/job/Thrift/162/])


> Union structs should have generated methods to test whether a specific field 
> is currently set 
> --
>
> Key: THRIFT-1199
> URL: https://issues.apache.org/jira/browse/THRIFT-1199
> Project: Thrift
>  Issue Type: Improvement
>  Components: Java - Compiler
>Reporter: Piotr Kozikowski
>Assignee: Piotr Kozikowski
>Priority: Trivial
> Fix For: 0.7
>
> Attachments: thrift-1199.patch
>
>
> For example, in the following union 
> {code}
> union MyUnion {
>   1: string my_field1;
>   2: string my_field2;
> }
> {code}
> it would be nice to be able to do something like {{boolean test = 
> myUnion.is_my_field1;}} as an alternative to {{boolean test = 
> (myUnion.getSetField() == _Fields.MY_FIELD1);}}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (THRIFT-1193) Potential infinite loop in nonblocking_server

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-1193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046867#comment-13046867
 ] 

Hudson commented on THRIFT-1193:


Integrated in Thrift #162 (See [https://builds.apache.org/job/Thrift/162/])


> Potential infinite loop in nonblocking_server
> -
>
> Key: THRIFT-1193
> URL: https://issues.apache.org/jira/browse/THRIFT-1193
> Project: Thrift
>  Issue Type: Bug
>  Components: Ruby - Library
>Affects Versions: 0.7
>Reporter: Ilya Maykov
>Assignee: Ilya Maykov
>Priority: Minor
> Fix For: 0.7
>
> Attachments: patch-THRIFT-1193.txt
>
>
> The fix for THRIFT-1187 could cause the server to enter an infinite loop if 
> select() started throwing Errno::EBADF when called on a non-closed 
> @server_transport.
> The obvious fix is to turn the 'next' into a 'break'.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (THRIFT-369) sets and maps break equality

[Ilya Maykov (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046846#comment-13046846
 ] 

Ilya Maykov commented on THRIFT-369:


I just tested this against thrift 0.6.0 and equality tests are working fine. 
I'll add the test code to the test suite sometime soon, at which point you can 
verify and mark as resolved.

> sets and maps break equality
> 
>
> Key: THRIFT-369
> URL: https://issues.apache.org/jira/browse/THRIFT-369
> Project: Thrift
>  Issue Type: Bug
>  Components: Ruby - Library
>Reporter: Bryan Duxbury
>Priority: Minor
>
> I've found that two structs that have value-equivalent sets or maps as values 
> for some reason cause struct's == to fail. This is inconsistent with other 
> languages.
> For example, this struct: 
> {code}
> struct {
>   set_byte_map: 2} }>,
>   map_byte_map: { {1=>1} => 1 }
> }
> {code}
> created twice independently will not be ==.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (THRIFT-1203) Java server returns JSON map items in the wrong order

[Roger Meier (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046836#comment-13046836
 ] 

Roger Meier commented on THRIFT-1203:
-

We need the *same behavior* for all languages whenever possible to have *best 
interoperability* between the implementations.

Unit Tests should use ThriftTest.thrift and implement the same response for 
each test case, that's the idea behind THRIFT-847

Yes, I would like to see a patch for that bug.


> Java server returns JSON map items in the wrong order
> -
>
> Key: THRIFT-1203
> URL: https://issues.apache.org/jira/browse/THRIFT-1203
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Compiler, Java - Library
>Affects Versions: 0.6, 0.7
>Reporter: Henrique Mendonca
>Priority: Minor
>  Labels: java, test, test-server
>
> This is a old bug I have forgotten to register.
> lib/js/test uses a Java server to run its unit tests, and by doing so I could 
> see that there is a small problem on the Java JSON map decoder.
> The unit test "testMap" should echo a map back to the client without 
> changing it, but it's messing up with the items order, e.g. {7=77, 8=88, 
> 9=99} returns {8=88, 9=99, 7=77}
> To run the server:
> thrift-trunk/lib/java$ ant compile-test
> thrift-trunk/lib/js/test$ ant testserver
> and go to http://localhost:8088/test/test.html
> Java test server console output:
> [java] Incoming content: 
> [1,"testMap",1,0,{"1":{"map":["i32","i32",3,{"7":77,"8":88,"9":99}]}}]
> [java] testMap({{8=88, 9=99, 7=77}})
> [java] Outgoing content: 
> [1,"testMap",2,0,{"0":{"map":["i32","i32",3,{"8":88,"9":99,"7":77}]}}]
> It's minor but it would be nice if any Java developer could have a look on it.
> Thanks a lot.
> ps.: the same works with a cpp server

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Build failed in Jenkins: Thrift #161

[Apache Jenkins Server]

See 

Changes:

[jfarrell] Thrift-1102: typo in configure.ac: "==" operator in 'test' (instead 
of "=")

Fixed incorrect operator check for have_cpp in configure.ac

[jfarrell] Thrift-1181: AS3 compiler generates incorrect code for setting 
default values in constructor
Client: as3
Patch: Ethan Urie

Fix generated statements syntax to remove :type of the variable.

--
[...truncated 1777 lines...]
make[5]: Leaving directory 
`
make[4]: Leaving directory 
`
make[3]: Leaving directory 
`
make[2]: Leaving directory 
`
Making check in csharp
make[2]: Entering directory 
`
make[2]: Nothing to be done for `check'.
make[2]: Leaving directory 
`
Making check in java
make[2]: Entering directory 
`
/usr/bin/ant 
Buildfile: 

setup.init:

mvn.ant.tasks.check:

mvn.ant.tasks.download:
  [get] Getting: 
http://repo1.maven.org/maven2/org/apache/maven/maven-ant-tasks/2.1.3/maven-ant-tasks-2.1.3.jar
  [get] To: 

  [get] Not modified - so not downloaded

mvn.init:
[artifact:dependencies] [WARNING] Overriding profile: 
'maven-ant-tasks-repo-profile' (source: pom) with new instance from source: pom

init:

compile:

dist:

BUILD SUCCESSFUL
Total time: 1 second
make  check-local
make[3]: Entering directory 
`
/usr/bin/ant 
Buildfile: 

setup.init:

mvn.ant.tasks.check:

mvn.ant.tasks.download:
  [get] Getting: 
http://repo1.maven.org/maven2/org/apache/maven/maven-ant-tasks/2.1.3/maven-ant-tasks-2.1.3.jar
  [get] To: 

  [get] Not modified - so not downloaded

mvn.init:
[artifact:dependencies] [WARNING] Overriding profile: 
'maven-ant-tasks-repo-profile' (source: pom) with new instance from source: pom

init:

compile:

dist:

BUILD SUCCESSFUL
Total time: 1 second
/usr/bin/ant  test
Buildfile: 

generate:
 [exec] 
[WARNING::41]
 64-bit constant "100" may not work in all languages.
 [exec] 
 [exec] 
[WARNING::169]
 64-bit constant "1099511627775" may not work in all languages.
 [exec] 
 [exec] 
[WARNING::179]
 64-bit constant "4294967295" may not work in all languages.
 [exec] 
 [exec] 
[WARNING::179]
 64-bit constant "1099511627775" may not work in all languages.
 [exec] 
 [exec] 
[WARNING::179]
 64-bit constant "281474976710655" may not work in all languages.
 [exec] 
 [exec] 
[WARNING::179]
 64-bit constant "72057594037927935" may not work in all languages.
 [exec] 
 [exec] 
[WARNING::179]
 64-bit constant "9223372036854775807" may not work in all languages.
 [exec] 
 [exec] 
[WARNING::188]
 64-bit constant "4294967295" may not work in all languages.
 [exec] 
 [exec] 
[WARNING::188]
 64-bit constant "1099511627775" may not work in all languages.
 [exec] 
 [exec] 
[WARNING::188]
 64-bit constant "281474976710655" may not work in all languages.
 [exec] 
 [exec] 
[WARNING::188]
 64-bit constant "72057594037927935" may not work in all languages.
 [exec] 
 [exec] 
[WARNING::188]
 64-bit constant "9223372036854775807" may not work in all languages.
 [exec] 
 [exec] 
[WARNING::197]
 64-bit con

[jira] [Commented] (THRIFT-1200) JS compiler generates code that clobbers existing namespaces

[Roger Meier (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-1200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046829#comment-13046829
 ] 

Roger Meier commented on THRIFT-1200:
-

recommitted a little modification: added {} for if clause as required by jslint
see broken build: https://builds.apache.org/job/Thrift/160/


> JS compiler generates code that clobbers existing namespaces
> 
>
> Key: THRIFT-1200
> URL: https://issues.apache.org/jira/browse/THRIFT-1200
> Project: Thrift
>  Issue Type: Bug
>  Components: JavaScript - Compiler
>Affects Versions: 0.6.1
> Environment: all
>Reporter: Ilya Maykov
>Assignee: Ilya Maykov
> Fix For: 0.7
>
> Attachments: THRIFT-1200-js-namespace-fix.txt
>
>
> The JavaScript compiler currently generates code that will clobber an 
> already-existing namespace. It should check if the namespace exists before 
> initializing it to {}. Example code pre-patch, assuming the .thrift file has 
> the declaration {{namespace js CompanyName.ModuleName}}:
> {code:JavaScript}
> var CompanyName = {};
> CompanyName.ModuleName = {}
> {code}
> Becomes this after patch:
> {code:JavaScript}
> if (typeof CompanyName === 'undefined') CompanyName = {};
> if (typeof CompanyName.ModuleName === 'undefined') CompanyName.ModuleName = 
> {};
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (THRIFT-113) to-string methods should omit optional null fields from output

[Jake Farrell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jake Farrell closed THRIFT-113.
---

   Resolution: Fixed
Fix Version/s: 0.7

All subtasks are resolved for this issue, closing ticket

> to-string methods should omit optional null fields from output
> --
>
> Key: THRIFT-113
> URL: https://issues.apache.org/jira/browse/THRIFT-113
> Project: Thrift
>  Issue Type: Improvement
>Reporter: Bryan Duxbury
>Priority: Trivial
> Fix For: 0.7
>
>
> We have structs with a lot of optional fields, and from a debugging 
> standpoint, when we print out such structs, all the null optional fields 
> pollute the printout with an enormous amount of noise. I think it would be 
> pretty handy if optional fields that were null were just omitted from the 
> print out entirely.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (THRIFT-1191) Erlang binding throws during skipping fields of composite type (maps, lists, structs, sets)

[Anatoly Kanivetsky (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anatoly Kanivetsky updated THRIFT-1191:
---

Attachment: THRIFT-1191.patch

> Erlang binding throws during skipping fields of composite type (maps, lists, 
> structs, sets)
> ---
>
> Key: THRIFT-1191
> URL: https://issues.apache.org/jira/browse/THRIFT-1191
> Project: Thrift
>  Issue Type: Bug
>  Components: Erlang - Library
>Reporter: Anatoly Kanivetsky
> Attachments: THRIFT-1191.patch
>
>
> Erlang binding throws during skipping fields of composite type (maps, lists, 
> structs, sets)
> Here's the pull request with this fix:
> https://github.com/apache/thrift/pull/3 here is the patch
> Here's the fix only:
> https://github.com/chaos-ad/thrift/commit/d70576209ae01f7ae56a1afccc1210d120b0ecde

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (THRIFT-1017) Cleanup whitespaces in sourcefiles

[Jake Farrell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jake Farrell closed THRIFT-1017.


Resolution: Not A Problem
  Assignee: Jake Farrell

Looking through the code base there are no tabs in any source files (.c, .cc, 
.h, .cs, .java, etc.), the only place i could find tabs where in makefiles. 
closing as non-issue, if this is a problem please submit a patch or a list of 
offending files and i will be glad to help with it.

> Cleanup whitespaces in sourcefiles
> --
>
> Key: THRIFT-1017
> URL: https://issues.apache.org/jira/browse/THRIFT-1017
> Project: Thrift
>  Issue Type: Improvement
>Reporter: Anatol Pomozov
>Assignee: Jake Farrell
>Priority: Trivial
>
> A couple of simple sed expressions can cleanup a bunch of TABS/incorrect 
> whitespaces in the source files
> // Replace TAB with whitespaces in source files
> find -type f -name *.c | xargs sed -i 's/\t/  /g'
> // We need to cleanup *.h *.cc *.java *.cs files as well
> // Remove trailing spaces
> find -type f | xargs sed -i 's/ *$//g'

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (THRIFT-1102) typo in configure.ac: "==" operator in 'test' (instead of"'=")

[Jake Farrell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-1102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jake Farrell closed THRIFT-1102.


   Resolution: Fixed
Fix Version/s: 0.7
 Assignee: Jake Farrell

Fixed incorrect operator check for have_cpp in configure.ac

> typo in configure.ac: "==" operator in 'test' (instead of"'=")
> --
>
> Key: THRIFT-1102
> URL: https://issues.apache.org/jira/browse/THRIFT-1102
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process
>Affects Versions: 0.6
>Reporter: Sergey Skvortsov
>Assignee: Jake Farrell
> Fix For: 0.7
>
>   Original Estimate: 20m
>  Remaining Estimate: 20m
>
> While:
> ./configure --with-cpp
> command "test" returns false because of incorrect operator "==" and as result 
> "cpp" library do not built.
> Patch:
> --- configure.ac.orig 2011-03-20 21:26:41.0 +
> +++ configure.ac  2011-03-20 21:26:57.0 +
> @@ -85,7 +85,7 @@
>  have_cpp=no
>  if test "$with_cpp" = "yes";  then
>AX_BOOST_BASE([1.33.1])
> -  if test "x$succeeded" == "xyes" ; then
> +  if test "x$succeeded" = "xyes" ; then
>  have_cpp="yes"
>fi
>  

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (THRIFT-1181) AS3 compiler generates incorrect code for setting default values in constructor

[Jake Farrell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jake Farrell closed THRIFT-1181.


   Resolution: Fixed
Fix Version/s: 0.7
 Assignee: Ethan Urie

Committed to trunk, thanks for the patch

> AS3 compiler generates incorrect code for setting default values in 
> constructor
> ---
>
> Key: THRIFT-1181
> URL: https://issues.apache.org/jira/browse/THRIFT-1181
> Project: Thrift
>  Issue Type: Bug
>  Components: AS3 - Compiler
>Affects Versions: 0.6, 0.6.1, 0.7
> Environment: Mac OS X 10.6.7
>Reporter: Ethan Urie
>Assignee: Ethan Urie
>Priority: Minor
> Fix For: 0.7
>
> Attachments: THRIFT-1181_correct_default_value_syntax.patch
>
>
> If you create a thrift struct and set a field to have a default value, the 
> compiler puts the code to set that default value in the constructor of the 
> generated class. When it does this, it adds {{:Type}} to the right of the 
> variable, e.g., {{this.count:int = 0;}}. The generated statement isn't 
> correct syntax and fails to compile. The correct syntax would simply be 
> {{this.count = 0;}}.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (THRIFT-418) Don't do runtime sorting of struct fields

[Ilya Maykov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ilya Maykov updated THRIFT-418:
---

Patch Info: [Patch Available]

> Don't do runtime sorting of struct fields
> -
>
> Key: THRIFT-418
> URL: https://issues.apache.org/jira/browse/THRIFT-418
> Project: Thrift
>  Issue Type: Improvement
>  Components: Ruby - Compiler, Ruby - Library
>Affects Versions: 0.1
>Reporter: Bryan Duxbury
>Priority: Minor
> Attachments: THRIFT-418-avoid-runtime-sorting-of-struct-fields.patch
>
>
> Currently the ruby struct code sorts the field ids of each struct every time 
> it is serialized, which is an unnecessary drag on performance. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (THRIFT-418) Don't do runtime sorting of struct fields

[Ilya Maykov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ilya Maykov updated THRIFT-418:
---

Attachment: THRIFT-418-avoid-runtime-sorting-of-struct-fields.patch

Attaching patch. There are 2 changes:

1) Modified t_rb_generator.cc to generate a FIELD_IDS constant for each struct 
+ a struct_field_ids() accessor method.

2) Use struct_field_ids.each instead of struct_fields.keys.sort.each to iterate 
through struct fields id-sorted order.

Updated the native code as well. All tests pass. Should be targeted for next 
major release as the change is not code-compatible with 0.6-generated files.

Can be re-implement without a compiler change if we want to keep full 
compatibility between 0.6 gen-rb files and 0.7 library.

> Don't do runtime sorting of struct fields
> -
>
> Key: THRIFT-418
> URL: https://issues.apache.org/jira/browse/THRIFT-418
> Project: Thrift
>  Issue Type: Improvement
>  Components: Ruby - Compiler, Ruby - Library
>Affects Versions: 0.1
>Reporter: Bryan Duxbury
>Priority: Minor
> Attachments: THRIFT-418-avoid-runtime-sorting-of-struct-fields.patch
>
>
> Currently the ruby struct code sorts the field ids of each struct every time 
> it is serialized, which is an unnecessary drag on performance. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Optional Struct Members in Go-Thrift Compiler

[Trevor Smith]

Bryan,

I looked through the Java library and see the "__isset_bit_vector"
field it generates. That's a good idea.

This would then require a change in the Go compiler to generate all of
the struct fields as lower case (internal), as opposed to external as
they currently are. This would prevent users from accessing the struct
variables, except through their accessor methods. Then the struct
accessor methods could do something similar to the __isset_bit_vector
pattern to correctly implement the "optional" fields.

This sounds reasonable to me.

Thoughts on this?

Thank you.

Trevor

On Wed, Jun 8, 2011 at 1:44 PM, Bryan Duxbury  wrote:
> In the Java library, we added extra "is set" flags for fields that could not
> be nulled out but could be not set.
>
> On Wed, Jun 8, 2011 at 10:38 AM, Trevor Smith  wrote:
>
>> Hello,
>>
>> The current Go compiler implementation in Thrift does not deal
>> correctly with optional struct values. This, for example, makes
>> compiling the Cassandra Thrift interface unusable, because it sends
>> along optional string values as zero length strings, when it should in
>> fact be skipping the field altogether.
>>
>> I am working on a patch to fix this. For many Go datatypes this is
>> straight forward (ie types that can be represented as nil in Go).
>> However, it is not clear to me how to generate Go code that does the
>> optional check for string and integer types -- specifically to allow a
>> string zero length string or an integer of value 0 in an optional
>> field, versus the non inclusion of those values. This is because Go
>> sets integer and string types to 0 and "", respectively, as their
>> default values.
>>
>> Literally, I do not know how to:
>>
>> // Create the code to make a decision as to include or not include a
>> struct field in
>> // t_go_compiler.cc: generate_go_struct_writer
>> if (item->get_req() == t_field::T_OPTIONAL && /* type is int and zero,
>> what to do? */( {
>> }
>>
>> Any suggestions would be appreciated.
>>
>> Thank you.
>>
>> Trevor Smith
>>
>

[jira] [Commented] (THRIFT-1191) Erlang binding throws during skipping fields of composite type (maps, lists, structs, sets)

[Bryan Duxbury (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046668#comment-13046668
 ] 

Bryan Duxbury commented on THRIFT-1191:
---

The clean patch would probably be the easiest thing at this point.

> Erlang binding throws during skipping fields of composite type (maps, lists, 
> structs, sets)
> ---
>
> Key: THRIFT-1191
> URL: https://issues.apache.org/jira/browse/THRIFT-1191
> Project: Thrift
>  Issue Type: Bug
>  Components: Erlang - Library
>Reporter: Anatoly Kanivetsky
>
> Erlang binding throws during skipping fields of composite type (maps, lists, 
> structs, sets)
> Here's the pull request with this fix:
> https://github.com/apache/thrift/pull/3 here is the patch
> Here's the fix only:
> https://github.com/chaos-ad/thrift/commit/d70576209ae01f7ae56a1afccc1210d120b0ecde

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (THRIFT-1203) Java server returns JSON map items in the wrong order

[T Jake Luciani (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046560#comment-13046560
 ] 

T Jake Luciani commented on THRIFT-1203:


Why does the order of the json matter?

> Java server returns JSON map items in the wrong order
> -
>
> Key: THRIFT-1203
> URL: https://issues.apache.org/jira/browse/THRIFT-1203
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Compiler, Java - Library
>Affects Versions: 0.6, 0.7
>Reporter: Henrique Mendonca
>Priority: Minor
>  Labels: java, test, test-server
>
> This is a old bug I have forgotten to register.
> lib/js/test uses a Java server to run its unit tests, and by doing so I could 
> see that there is a small problem on the Java JSON map decoder.
> The unit test "testMap" should echo a map back to the client without 
> changing it, but it's messing up with the items order, e.g. {7=77, 8=88, 
> 9=99} returns {8=88, 9=99, 7=77}
> To run the server:
> thrift-trunk/lib/java$ ant compile-test
> thrift-trunk/lib/js/test$ ant testserver
> and go to http://localhost:8088/test/test.html
> Java test server console output:
> [java] Incoming content: 
> [1,"testMap",1,0,{"1":{"map":["i32","i32",3,{"7":77,"8":88,"9":99}]}}]
> [java] testMap({{8=88, 9=99, 7=77}})
> [java] Outgoing content: 
> [1,"testMap",2,0,{"0":{"map":["i32","i32",3,{"8":88,"9":99,"7":77}]}}]
> It's minor but it would be nice if any Java developer could have a look on it.
> Thanks a lot.
> ps.: the same works with a cpp server

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (THRIFT-1203) Java server returns JSON map items in the wrong order

[Henrique Mendonca (JIRA)]

Java server returns JSON map items in the wrong order
-

 Key: THRIFT-1203
 URL: https://issues.apache.org/jira/browse/THRIFT-1203
 Project: Thrift
  Issue Type: Bug
  Components: Java - Compiler, Java - Library
Affects Versions: 0.6, 0.7
Reporter: Henrique Mendonca
Priority: Minor


This is a old bug I have forgotten to register.
lib/js/test uses a Java server to run its unit tests, and by doing so I could 
see that there is a small problem on the Java JSON map decoder.

The unit test "testMap" should echo a map back to the client without 
changing it, but it's messing up with the items order, e.g. {7=77, 8=88, 9=99} 
returns {8=88, 9=99, 7=77}

To run the server:
thrift-trunk/lib/java$ ant compile-test
thrift-trunk/lib/js/test$ ant testserver
and go to http://localhost:8088/test/test.html

Java test server console output:
[java] Incoming content: 
[1,"testMap",1,0,{"1":{"map":["i32","i32",3,{"7":77,"8":88,"9":99}]}}]
[java] testMap({{8=88, 9=99, 7=77}})
[java] Outgoing content: 
[1,"testMap",2,0,{"0":{"map":["i32","i32",3,{"8":88,"9":99,"7":77}]}}]

It's minor but it would be nice if any Java developer could have a look on it.
Thanks a lot.

ps.: the same works with a cpp server

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (THRIFT-1202) Malformed JSON for map services parameters

[Henrique Mendonca (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-1202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046536#comment-13046536
 ] 

Henrique Mendonca commented on THRIFT-1202:
---

ah sorry, this patch also includes some tests for THRIFT-1150, but I think they 
could also be included...

> Malformed JSON for map services parameters
> ---
>
> Key: THRIFT-1202
> URL: https://issues.apache.org/jira/browse/THRIFT-1202
> Project: Thrift
>  Issue Type: Bug
>  Components: JavaScript - Compiler, JavaScript - Library
>Affects Versions: 0.7
> Environment: Firefox 3.6.16 || 4.0.1
>Reporter: Henrique Mendonca
>  Labels: javascript
> Attachments: qunit-tests-java-test-server.patch
>
>
> I have a problem if I try to use Strings as map keys. Somehow I get two 
> double quotes around the key values, e.g. ""key"" instead of "key":
> testStringMap({'a':'123', 'a b':'with spaces', 'test':'test', ... }) sends:
> [1,"testStringMap",1,0,{"1":{"map":["str","str",5,{""a"":"123",""a b"":"with 
> spaces",""test"":"test", ... }]}}]
> I guess it's something wrong on the write methods from compiled JS services...
> Could someone test this on their machine? Thank you.
> Cheers,
> Henrique

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (THRIFT-1202) Malformed JSON for map services parameters

[Henrique Mendonca (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-1202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Henrique Mendonca updated THRIFT-1202:
--

Attachment: qunit-tests-java-test-server.patch

> Malformed JSON for map services parameters
> ---
>
> Key: THRIFT-1202
> URL: https://issues.apache.org/jira/browse/THRIFT-1202
> Project: Thrift
>  Issue Type: Bug
>  Components: JavaScript - Compiler, JavaScript - Library
>Affects Versions: 0.7
> Environment: Firefox 3.6.16 || 4.0.1
>Reporter: Henrique Mendonca
>  Labels: javascript
> Attachments: qunit-tests-java-test-server.patch
>
>
> I have a problem if I try to use Strings as map keys. Somehow I get two 
> double quotes around the key values, e.g. ""key"" instead of "key":
> testStringMap({'a':'123', 'a b':'with spaces', 'test':'test', ... }) sends:
> [1,"testStringMap",1,0,{"1":{"map":["str","str",5,{""a"":"123",""a b"":"with 
> spaces",""test"":"test", ... }]}}]
> I guess it's something wrong on the write methods from compiled JS services...
> Could someone test this on their machine? Thank you.
> Cheers,
> Henrique

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (THRIFT-1202) Malformed JSON for map services parameters

[Henrique Mendonca (JIRA)]

Malformed JSON for map services parameters
---

 Key: THRIFT-1202
 URL: https://issues.apache.org/jira/browse/THRIFT-1202
 Project: Thrift
  Issue Type: Bug
  Components: JavaScript - Compiler, JavaScript - Library
Affects Versions: 0.7
 Environment: Firefox 3.6.16 || 4.0.1
Reporter: Henrique Mendonca
 Attachments: qunit-tests-java-test-server.patch

I have a problem if I try to use Strings as map keys. Somehow I get two double 
quotes around the key values, e.g. ""key"" instead of "key":

testStringMap({'a':'123', 'a b':'with spaces', 'test':'test', ... }) sends:

[1,"testStringMap",1,0,{"1":{"map":["str","str",5,{""a"":"123",""a b"":"with 
spaces",""test"":"test", ... }]}}]

I guess it's something wrong on the write methods from compiled JS services...
Could someone test this on their machine? Thank you.

Cheers,
Henrique

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (THRIFT-1191) Erlang binding throws during skipping fields of composite type (maps, lists, structs, sets)

[Anatoly Kanivetsky (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046401#comment-13046401
 ] 

Anatoly Kanivetsky commented on THRIFT-1191:


Yes.
Sorry for this, but I'm new to git and github, so I don't know how to split it 
up.
If there is no way to do this - I can post the clean patch (which can be 
extracted from github anyway).

> Erlang binding throws during skipping fields of composite type (maps, lists, 
> structs, sets)
> ---
>
> Key: THRIFT-1191
> URL: https://issues.apache.org/jira/browse/THRIFT-1191
> Project: Thrift
>  Issue Type: Bug
>  Components: Erlang - Library
>Reporter: Anatoly Kanivetsky
>
> Erlang binding throws during skipping fields of composite type (maps, lists, 
> structs, sets)
> Here's the pull request with this fix:
> https://github.com/apache/thrift/pull/3 here is the patch
> Here's the fix only:
> https://github.com/chaos-ad/thrift/commit/d70576209ae01f7ae56a1afccc1210d120b0ecde

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira