[jira] [Commented] (THRIFT-1907) Compiling namespace and sub-namespace directives for unrecognized generators should only be a warning
[ https://issues.apache.org/jira/browse/THRIFT-1907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13661658#comment-13661658 ] Henrique Mendonca commented on THRIFT-1907: --- Committed. Thanks Andrew! > Compiling namespace and sub-namespace directives for unrecognized generators > should only be a warning > - > > Key: THRIFT-1907 > URL: https://issues.apache.org/jira/browse/THRIFT-1907 > Project: Thrift > Issue Type: Bug > Components: Compiler (General) >Affects Versions: 0.9 >Reporter: Andrew Cox >Assignee: Henrique Mendonca >Priority: Minor > Labels: patch > Fix For: 1.0 > > Attachments: THRIFT-1907.patch > > > Two reasons: > 1) we have another generator that we want to use a different namespace for, > and the generator is not part of thrift proper > 2) back compat: so two projects that depend on two different versions of > thrift are more likely to be able to share a .thrift file, even if the > project using the newer thrift libraries uses a new generator that wasn't in > the old thrift libraries -- 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] [Closed] (THRIFT-1907) Compiling namespace and sub-namespace directives for unrecognized generators should only be a warning
[ https://issues.apache.org/jira/browse/THRIFT-1907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henrique Mendonca closed THRIFT-1907. - Resolution: Fixed > Compiling namespace and sub-namespace directives for unrecognized generators > should only be a warning > - > > Key: THRIFT-1907 > URL: https://issues.apache.org/jira/browse/THRIFT-1907 > Project: Thrift > Issue Type: Bug > Components: Compiler (General) >Affects Versions: 0.9 >Reporter: Andrew Cox >Assignee: Henrique Mendonca >Priority: Minor > Labels: patch > Fix For: 1.0 > > Attachments: THRIFT-1907.patch > > > Two reasons: > 1) we have another generator that we want to use a different namespace for, > and the generator is not part of thrift proper > 2) back compat: so two projects that depend on two different versions of > thrift are more likely to be able to share a .thrift file, even if the > project using the newer thrift libraries uses a new generator that wasn't in > the old thrift libraries -- 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] (THRIFT-1973) TCompactProtocol in C# lib does not serialize and deserialize negative int32 and int64 number correctly
[ https://issues.apache.org/jira/browse/THRIFT-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13661647#comment-13661647 ] Henrique Mendonca commented on THRIFT-1973: --- Hi Eric, Thanks for you patch. Are both your client and server running C#? Would you be able to provide us some unit-testing to reproduce that? We are already using this on production code and the cases you mentioned were successfully tested against a c++ server, but yes, this could be a problem on the other side. Ideally, we should make the existing tests to optionally use compact binary to check this. Cheers, Henrique > TCompactProtocol in C# lib does not serialize and deserialize negative int32 > and int64 number correctly > --- > > Key: THRIFT-1973 > URL: https://issues.apache.org/jira/browse/THRIFT-1973 > Project: Thrift > Issue Type: Bug > Components: C# - Library >Affects Versions: 0.9, 1.0 > Environment: Windows >Reporter: Eric Ding > Labels: PatchAvailable > Fix For: 1.0 > > Attachments: thrift-1973-TCompactProtocol-Fix.patch > > > longToZigzag and ZigzagToLong in TCompactProtocol does not perform > corresponding operations to serialize and deserialize negative int32 and > int64 number correctly. Purpose to change longToZigzag from > (ulong)(((ulong)n << 1) ^ ((ulong)n >> 63)) to (ulong)(n << 1) ^ (ulong)(n >> > 63). > Will need to do same for intToZigZag. The reason is that we want arithmetic > shift not logic shift. > The test case in the project shows this, the output on server and client are > different even though client received the same number back. -- 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] (THRIFT-1893) HTTP server/client for node js
[ https://issues.apache.org/jira/browse/THRIFT-1893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13659979#comment-13659979 ] Henrique Mendonca commented on THRIFT-1893: --- currently we have unittests "lib/nodejs/test" and integration tests "test/nodejs" you can run "make -C test/nodejs check" to test both of them or "sh test/test.sh" to run the cross language tests (important for us here are js-java and node-cpp, so we could eventually add a js-node) Please check the latest version from the repository. Later on we should be also able to add parameters to test/nodejs/server and client to switch between the protocols, transports, etc, but that's another thing. Thanks for making Thrift better! ;) > HTTP server/client for node js > -- > > Key: THRIFT-1893 > URL: https://issues.apache.org/jira/browse/THRIFT-1893 > Project: Thrift > Issue Type: New Feature > Components: Node.js - Library >Affects Versions: 0.9 >Reporter: Phillip Campbell >Priority: Minor > Labels: node > Fix For: 1.0 > > Attachments: thrift-1893-node-http.patch > > > I have written a http server for node js, and am in progress on a http client > for node js. I will contribute a patch file when I am done, however I am > having a few problems figuring out how things need to be implemented. I am > trying to follow the ruby implementation as an example, but am unsure how to > make sure I implement things correct. I assume the link in the README under > requirements was supposed to explain these things, but currently > http://wiki.apache.org/thrift/ThriftRequirements leads to gibberish. > Questions I have are: > Do I need to implement a JSON protocol? > On an http request, do I need to ensure the request is a POST? Check for > headers? What is required? > Thanks -- 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] (THRIFT-1893) HTTP server/client for node js
[ https://issues.apache.org/jira/browse/THRIFT-1893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henrique Mendonca updated THRIFT-1893: -- Affects Version/s: 0.9 > HTTP server/client for node js > -- > > Key: THRIFT-1893 > URL: https://issues.apache.org/jira/browse/THRIFT-1893 > Project: Thrift > Issue Type: New Feature > Components: Node.js - Library >Affects Versions: 0.9 >Reporter: Phillip Campbell >Priority: Minor > Labels: node > Attachments: thrift-1893-node-http.patch > > > I have written a http server for node js, and am in progress on a http client > for node js. I will contribute a patch file when I am done, however I am > having a few problems figuring out how things need to be implemented. I am > trying to follow the ruby implementation as an example, but am unsure how to > make sure I implement things correct. I assume the link in the README under > requirements was supposed to explain these things, but currently > http://wiki.apache.org/thrift/ThriftRequirements leads to gibberish. > Questions I have are: > Do I need to implement a JSON protocol? > On an http request, do I need to ensure the request is a POST? Check for > headers? What is required? > Thanks -- 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] (THRIFT-1893) HTTP server/client for node js
[ https://issues.apache.org/jira/browse/THRIFT-1893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henrique Mendonca updated THRIFT-1893: -- Fix Version/s: 1.0 > HTTP server/client for node js > -- > > Key: THRIFT-1893 > URL: https://issues.apache.org/jira/browse/THRIFT-1893 > Project: Thrift > Issue Type: New Feature > Components: Node.js - Library >Affects Versions: 0.9 >Reporter: Phillip Campbell >Priority: Minor > Labels: node > Fix For: 1.0 > > Attachments: thrift-1893-node-http.patch > > > I have written a http server for node js, and am in progress on a http client > for node js. I will contribute a patch file when I am done, however I am > having a few problems figuring out how things need to be implemented. I am > trying to follow the ruby implementation as an example, but am unsure how to > make sure I implement things correct. I assume the link in the README under > requirements was supposed to explain these things, but currently > http://wiki.apache.org/thrift/ThriftRequirements leads to gibberish. > Questions I have are: > Do I need to implement a JSON protocol? > On an http request, do I need to ensure the request is a POST? Check for > headers? What is required? > Thanks -- 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] (THRIFT-1893) HTTP server/client for node js
[ https://issues.apache.org/jira/browse/THRIFT-1893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13659892#comment-13659892 ] Henrique Mendonca commented on THRIFT-1893: --- Hi Phillip, thanks so much for this patch! It's really a shame that no one has seen this before. I'd commit your patch but shouldn't we divide the servers and protocol into different files/folders? e.g.: server/server_tcp.js, server/server_http.js and protocol/protocol_json.js, protocol/protocol_binary.js I'm afraid it will get really confusing to have everything together. For the client we could additionally also use the normal JavaScript test client, for that we'd only need to be able to serve static files too, like on "ant -f lib/js/test/build.xml unittest" What do you think? > HTTP server/client for node js > -- > > Key: THRIFT-1893 > URL: https://issues.apache.org/jira/browse/THRIFT-1893 > Project: Thrift > Issue Type: New Feature > Components: Node.js - Library >Reporter: Phillip Campbell >Priority: Minor > Labels: node > Attachments: thrift-1893-node-http.patch > > > I have written a http server for node js, and am in progress on a http client > for node js. I will contribute a patch file when I am done, however I am > having a few problems figuring out how things need to be implemented. I am > trying to follow the ruby implementation as an example, but am unsure how to > make sure I implement things correct. I assume the link in the README under > requirements was supposed to explain these things, but currently > http://wiki.apache.org/thrift/ThriftRequirements leads to gibberish. > Questions I have are: > Do I need to implement a JSON protocol? > On an http request, do I need to ensure the request is a POST? Check for > headers? What is required? > Thanks -- 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] (THRIFT-1907) Compiling namespace and sub-namespace directives for unrecognized generators should only be a warning
[ https://issues.apache.org/jira/browse/THRIFT-1907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henrique Mendonca updated THRIFT-1907: -- Assignee: Henrique Mendonca > Compiling namespace and sub-namespace directives for unrecognized generators > should only be a warning > - > > Key: THRIFT-1907 > URL: https://issues.apache.org/jira/browse/THRIFT-1907 > Project: Thrift > Issue Type: Bug > Components: Compiler (General) >Affects Versions: 0.9 >Reporter: Andrew Cox >Assignee: Henrique Mendonca >Priority: Minor > Labels: patch > Fix For: 1.0 > > Attachments: THRIFT-1907.patch > > > Two reasons: > 1) we have another generator that we want to use a different namespace for, > and the generator is not part of thrift proper > 2) back compat: so two projects that depend on two different versions of > thrift are more likely to be able to share a .thrift file, even if the > project using the newer thrift libraries uses a new generator that wasn't in > the old thrift libraries -- 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] (THRIFT-1841) NodeJS Thrift incorrectly parses non-UTF8-string types
[
https://issues.apache.org/jira/browse/THRIFT-1841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13655600#comment-13655600
]
Henrique Mendonca commented on THRIFT-1841:
---
Hi Nabeel,
Anything else on this?
I could not really reproduce this, would you have a test case for it? It'd e
really handy if you could attach one here.
The protocol readString is always called to read/write the service name, but I
can't see the relation to the bug with doubles. We might have a problem with
complex maps embedded in structures as we had similar problems with the
JavaScript library.
> NodeJS Thrift incorrectly parses non-UTF8-string types
> --
>
> Key: THRIFT-1841
> URL: https://issues.apache.org/jira/browse/THRIFT-1841
> Project: Thrift
> Issue Type: Bug
> Components: Node.js - Compiler, Node.js - Library
>Affects Versions: 0.9, 1.0
>Reporter: Nabeel Shahzad
>
> **Edit**: See my comment below.
> When a double/float is used in a map (key or value), list, or set types, the
> decoding is done as a utf8 string, which then incorrectly parses and adds
> extra bytes.
> For example:
> The bytes of a map (this is coming out of the Thrift call)
> {noformat}
> 00 01 00 08 3f f4 00 00 00 00 00 00 00 08 40 02 00 00 00 00 00 00
> {noformat}
> But after it's been parsed out from the field as UTF8:
> {noformat}
> 00 01 00 08 3f 3f 00 00 00 00 00 00 00 08 40 02 00 00 00 00 00 00
> {noformat}
> As you can see there's an incorrect byte (the 3f where the f4, and an extra
> 00). For reference, this value was map = {1.25: 2.25}. This
> is the same behavior for floats. The f4 translated to ASCII 247, which I
> believe isn't a valid utf8 code.
> The actual value of the field becomes:
> {noformat}
> value:
> '\u\u0002\u\b??\u\u\u\u\u\u\u\b@\u0002\u\u\u\u\u\u''
> {noformat}
> Where the \b = 8, ? = f4, ? = unknown char.
> I have seen cases where there are *extra* bytes added in, which breaks the
> parsing based on byte size:
> {noformat}
> 00 01 00 08 40 24 48 72 c2 b0 20 c3 84 c2 9c 00 08 40 34 c3 bc c3 93 5a c2 85
> c2 87 c2 94
> {noformat}
> Where the MAP value was {10.1415, 20.9876}. On a list or set, using either
> value also yields extra bytes.
> So this messes up any parsing based on the byte-length for the field, since
> there are a variable number of extra bytes added, either to the key or value
> of the map, and any values of a list. I believe this could also happen on
> high-integer values.
> It seems to me when the "ftype" is parsed (int16) before the actual field,
> it's returning a TYPE value of "11" (string) - instead of the proper value of
> a map/set/list.
> For reference, the table, and an insert example:
> {noformat}
> CREATE TABLE sample_map (
> id text PRIMARY KEY,
> map_col_text map < text, text >,
> map_col_int map < int, text >,
> map_col_float map < float, float >,
> map_col_double map < double, double >
> );
> INSERT INTO sample_map (id, map_col_double) VALUES('DOUBLE_ROW_SINGLE',
> {10.1415: 20.9876});
> {noformat}
> Not sure if it matters, but this was using CQL3. Also, we are not seeing this
> on the C++ generated Thrift interface.
> Versions:
> {noformat}
> cqlsh:orion> show version;
> [cqlsh 2.3.0 | Cassandra 1.2.0 | CQL spec 3.0.0 | Thrift protocol 19.35.0]
> {noformat}
> {noformat}
> $ thrift --version
> Thrift version 0.9.0
> {noformat}
> {noformat}
> "name": "node-thrift",
> "description": "node.js bindings for the Apache Thrift RPC system",
> "homepage": "http://thrift.apache.org/";,
> "repository": {
> "type": "svn",
> "url": "http://svn.apache.org/repos/asf/thrift/trunk/";
> },
> "version": "1.0.0-dev",
> {noformat}
> The issue also appears in the 0.9.0 version of the thrift library.
--
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] [Closed] (THRIFT-1679) NodeJS: protocol readString() should treat string as utf8, not binary
[
https://issues.apache.org/jira/browse/THRIFT-1679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henrique Mendonca closed THRIFT-1679.
-
Resolution: Implemented
Fix Version/s: 0.9
> NodeJS: protocol readString() should treat string as utf8, not binary
> -
>
> Key: THRIFT-1679
> URL: https://issues.apache.org/jira/browse/THRIFT-1679
> Project: Thrift
> Issue Type: Bug
> Components: Node.js - Library
>Affects Versions: 0.8
> Environment: All
>Reporter: Michael Fleming
> Fix For: 0.9
>
>
> Using Node.js's Thrift library to talk to Hive:
> a) Read back a Hive result that contains utf8 characters
> Expected:
> - Get a Javascript string object that contains the correct utf8 sequence
> Actual:
> - Get a Javascript sequence that is indicative of UTF8 double-encoding
> Underlying:
> In protocol.js, change "readString()"
> var r = this.readBinary().toString('binary');
> to this:
> var r = this.readBinary().toString('utf8');
> Per http://thrift.apache.org/docs/types/
> "string: A text string encoded using UTF-8 encoding"
--
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] (THRIFT-1349) Remove unnecessary print outs
[ https://issues.apache.org/jira/browse/THRIFT-1349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henrique Mendonca updated THRIFT-1349: -- Component/s: Erlang - Library > Remove unnecessary print outs > - > > Key: THRIFT-1349 > URL: https://issues.apache.org/jira/browse/THRIFT-1349 > Project: Thrift > Issue Type: Improvement > Components: Erlang - Library >Affects Versions: 0.7 >Reporter: Anthony Molinaro >Assignee: Anthony Molinaro > Attachments: THRIFT-1349.patch > > > There are a couple of spurious error_logger:info_msg/2 calls which can lead > to lots of output when talking between slightly different versions of > generated code. For instance launching a server which returns a new field to > a client will result in the client printing out information about an unknown > fid. This leads to lots of logging which you probably don't want. I'd like > to remove these unless anyone in dev objects. -- 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] (THRIFT-1349) Remove unnecessary print outs
[ https://issues.apache.org/jira/browse/THRIFT-1349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henrique Mendonca updated THRIFT-1349: -- Labels: erlang (was: ) > Remove unnecessary print outs > - > > Key: THRIFT-1349 > URL: https://issues.apache.org/jira/browse/THRIFT-1349 > Project: Thrift > Issue Type: Improvement > Components: Erlang - Library >Affects Versions: 0.7 >Reporter: Anthony Molinaro >Assignee: Anthony Molinaro > Labels: erlang > Attachments: THRIFT-1349.patch > > > There are a couple of spurious error_logger:info_msg/2 calls which can lead > to lots of output when talking between slightly different versions of > generated code. For instance launching a server which returns a new field to > a client will result in the client printing out information about an unknown > fid. This leads to lots of logging which you probably don't want. I'd like > to remove these unless anyone in dev objects. -- 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] [Resolved] (THRIFT-1967) Node.js tests don't cover all services
[ https://issues.apache.org/jira/browse/THRIFT-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henrique Mendonca resolved THRIFT-1967. --- Resolution: Fixed > Node.js tests don't cover all services > -- > > Key: THRIFT-1967 > URL: https://issues.apache.org/jira/browse/THRIFT-1967 > Project: Thrift > Issue Type: Test > Components: Node.js - Library >Affects Versions: 0.9 >Reporter: Henrique Mendonca >Assignee: Henrique Mendonca > Attachments: THRIFT-1967-node-tests.patch > > > Node.js still doesn't have a proper coverage on its tests. > This is my tentative to align it at least with the tests we have for the > original JS library. -- 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] [Closed] (THRIFT-1967) Node.js tests don't cover all services
[ https://issues.apache.org/jira/browse/THRIFT-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henrique Mendonca closed THRIFT-1967. - > Node.js tests don't cover all services > -- > > Key: THRIFT-1967 > URL: https://issues.apache.org/jira/browse/THRIFT-1967 > Project: Thrift > Issue Type: Test > Components: Node.js - Library >Affects Versions: 0.9 >Reporter: Henrique Mendonca >Assignee: Henrique Mendonca > Attachments: THRIFT-1967-node-tests.patch > > > Node.js still doesn't have a proper coverage on its tests. > This is my tentative to align it at least with the tests we have for the > original JS library. -- 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] (THRIFT-1967) Node.js tests don't cover all services
[ https://issues.apache.org/jira/browse/THRIFT-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henrique Mendonca updated THRIFT-1967: -- Attachment: THRIFT-1967-node-tests.patch Patch align with the tests we already have for the original JS and C++ libraries. it also corrects two small bugs on the test server and add nodejs to travis and make check ps.: still something wrong with the generation of TExceptions > Node.js tests don't cover all services > -- > > Key: THRIFT-1967 > URL: https://issues.apache.org/jira/browse/THRIFT-1967 > Project: Thrift > Issue Type: Test > Components: Node.js - Library >Affects Versions: 0.9 >Reporter: Henrique Mendonca >Assignee: Henrique Mendonca > Attachments: THRIFT-1967-node-tests.patch > > > Node.js still doesn't have a proper coverage on its tests. > This is my tentative to align it at least with the tests we have for the > original JS library. -- 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] [Created] (THRIFT-1967) Node.js tests don't cover all services
Henrique Mendonca created THRIFT-1967: - Summary: Node.js tests don't cover all services Key: THRIFT-1967 URL: https://issues.apache.org/jira/browse/THRIFT-1967 Project: Thrift Issue Type: Test Components: Node.js - Library Affects Versions: 0.9 Reporter: Henrique Mendonca Assignee: Henrique Mendonca Node.js still doesn't have a proper coverage on its tests. This is my tentative to align it at least with the tests we have for the original JS library. -- 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] [Closed] (THRIFT-1821) problem with sending request with Cyrillic in UTF-8 from node.js to java.
[
https://issues.apache.org/jira/browse/THRIFT-1821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henrique Mendonca closed THRIFT-1821.
-
Resolution: Cannot Reproduce
Same as for the other ticket, thanks for reporting it but I extended the nodejs
tests but I could not reproduce it, neither with buffered nor framed
transports, node nor java servers (thrift/test/nodejs "make check").
Perhaps have a look on the latest version from our repository and let us know.
Please send us a patch here, if you have a solution or can reproduce it with
the unit-tests.
http://wiki.apache.org/thrift/HowToContribute
> problem with sending request with Cyrillic in UTF-8 from node.js to java.
> ---
>
> Key: THRIFT-1821
> URL: https://issues.apache.org/jira/browse/THRIFT-1821
> Project: Thrift
> Issue Type: Bug
> Components: Java - Library, Node.js - Compiler, Node.js - Library
>Affects Versions: 0.9
>Reporter: Ihor Mysak
>
> Hi guys,
> I used thrift to communicate my services written on java and node.js. (all
> servers on java, clients on java and on node.js). this bug reproduces just on
> node.js client.
> In my source I write
> ...
> struct = new appSearch.ttypes.ASearchRequest(params);
> console.log(struct);
> appSearch.client.search(struct, function(err, result) {
> ...
> With latin query all is ok, but with Cyrillic its return an error
> { query: 'ф',
> tags: null,
> categoryIds: null,
> platforms: null,
> stores: null,
> ratings: null,
> price: null,
> withFacets: true,
> retrieveCountByTitle: false,
> withSpellcheck: false,
> orders: null,
> offset: 0,
> size: 10 } // this is console.log(struct);
> { name: 'TApplicationException',
> type: 7,
> message: 'Required field \'withFacets\' was not found in serialized data!
> Struct:
> com.airupt.searcher.thrift.ASearchRequest$ASearchRequestStandardScheme@1140382'
> } // this is console.log(err);
> my ASearchRequest structure
> struct ASearchRequest {
> 1:optional string query,
> 2:optional set tags,
> 3:optional set categoryIds,
> 4:optional set platforms,
> 5:optional set stores,
> 6:optional set ratings,
> 7:optional PriceFilter price,
>
> 8:required bool withFacets,
> 9:required bool retrieveCountByTitle,
> 10:required bool withSpellcheck,
>
> 11:optional list orders,
> 12:required i32 offset,
> 13:required i32 size
> }
> As I said follow, with latin in requests all works correct.
> Can any one help me with it ?
> transport: thrift.transport.TBufferedTransport
> protocol: thrift.protocol.TBinaryProtocol
--
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] [Closed] (THRIFT-1963) problem with deserialization field with type "double" in node.js client
[ https://issues.apache.org/jira/browse/THRIFT-1963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henrique Mendonca closed THRIFT-1963. - Resolution: Cannot Reproduce I extended the nodejs tests with exactly your example but I could not reproduce it, neither with buffered nor framed transports (thrift/test/nodejs "make check"). Perhaps have a look on the latest version from our repository and let us know. Please send us a patch here, if you have a solution or can reproduce it with the unit-tests. > problem with deserialization field with type "double" in node.js client > --- > > Key: THRIFT-1963 > URL: https://issues.apache.org/jira/browse/THRIFT-1963 > Project: Thrift > Issue Type: Bug > Components: Node.js - Compiler, Node.js - Library >Affects Versions: 0.9 >Reporter: Ihor Mysak >Priority: Critical > > My Java thrift server retrieve some object with few "double" fields. > Java clients can successful receive and deserialize object. But node.js > client (which use same api) receive object but with wrong values in double > fields. > example > server return 7.012052175215044 > client receive(after wrong deserialization) 1.9038419066418143e+24 -- 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] [Closed] (THRIFT-1957) NodeJS TFramedTransport and TBufferedTransport read bytes as unsigned
[ https://issues.apache.org/jira/browse/THRIFT-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henrique Mendonca closed THRIFT-1957. - Matthew, I was actually thinking about update the Expresso tests to Mocha, but I guess we can keep nodeunit since it is pretty standard too. We should probably add it to the projects dependencies and also use it for the client/server tests at thrift/tests/nodejs. Cheers, Henrique > NodeJS TFramedTransport and TBufferedTransport read bytes as unsigned > - > > Key: THRIFT-1957 > URL: https://issues.apache.org/jira/browse/THRIFT-1957 > Project: Thrift > Issue Type: Bug > Components: Node.js - Library >Affects Versions: 0.9 > Environment: NodeJS 10.4, Thrift 0.9 >Reporter: Matthew Imrie >Assignee: Henrique Mendonca > Labels: patch > Fix For: 1.0 > > Attachments: nodejs-thrift-signed-byte-fix.patch > > > Thrift for NodeJS is reading bytes as unsigned. The Apache Thrift > specification describes them as signed. > I changed the readByte function in both TFramedTransport and > TBufferedTransport to call a new readByte method in binary.js that properly > converts to a signed byte. Unit test for the method is included in > binary.test.js -- 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] [Resolved] (THRIFT-1957) NodeJS TFramedTransport and TBufferedTransport read bytes as unsigned
[ https://issues.apache.org/jira/browse/THRIFT-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henrique Mendonca resolved THRIFT-1957. --- Resolution: Fixed Fix Version/s: 1.0 Assignee: Henrique Mendonca Thanks for the patch Matthew > NodeJS TFramedTransport and TBufferedTransport read bytes as unsigned > - > > Key: THRIFT-1957 > URL: https://issues.apache.org/jira/browse/THRIFT-1957 > Project: Thrift > Issue Type: Bug > Components: Node.js - Library >Affects Versions: 0.9 > Environment: NodeJS 10.4, Thrift 0.9 >Reporter: Matthew Imrie >Assignee: Henrique Mendonca > Labels: patch > Fix For: 1.0 > > Attachments: nodejs-thrift-signed-byte-fix.patch > > > Thrift for NodeJS is reading bytes as unsigned. The Apache Thrift > specification describes them as signed. > I changed the readByte function in both TFramedTransport and > TBufferedTransport to call a new readByte method in binary.js that properly > converts to a signed byte. Unit test for the method is included in > binary.test.js -- 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] (THRIFT-1952) Travis CI
[ https://issues.apache.org/jira/browse/THRIFT-1952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13646463#comment-13646463 ] Henrique Mendonca commented on THRIFT-1952: --- forgot my vote: +10, since travis can also automatically test pull requests on github, and their servers are able to really test all language targets we have. Hopefully we will eventually be able to solve the license issue with github pull requests. > Travis CI > - > > Key: THRIFT-1952 > URL: https://issues.apache.org/jira/browse/THRIFT-1952 > Project: Thrift > Issue Type: Bug > Components: Build Process >Reporter: Roger Meier >Assignee: Roger Meier > Attachments: .travis.yml > > > I think, a travis build file is useful for the project. > see: https://github.com/bufferoverflow/thrift/blob/travis/.travis.yml -- 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] (THRIFT-1952) Travis CI
[ https://issues.apache.org/jira/browse/THRIFT-1952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13646458#comment-13646458 ] Henrique Mendonca commented on THRIFT-1952: --- cool! you fixed the missing stuff too! Cheers Roger and yeah the csharp doc is not up to date anymore but I think mono-gmcs libmono-system-web2.0-cil is enough since it includes whole rest.. Perhaps Jens can confirm it? thanks again Henrique > Travis CI > - > > Key: THRIFT-1952 > URL: https://issues.apache.org/jira/browse/THRIFT-1952 > Project: Thrift > Issue Type: Bug > Components: Build Process >Reporter: Roger Meier >Assignee: Roger Meier > Attachments: .travis.yml > > > I think, a travis build file is useful for the project. > see: https://github.com/bufferoverflow/thrift/blob/travis/.travis.yml -- 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] (THRIFT-1850) make check hangs on TSocket tests in TransportTest.cpp
[ https://issues.apache.org/jira/browse/THRIFT-1850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13640221#comment-13640221 ] Henrique Mendonca commented on THRIFT-1850: --- Hi Randy, Thanks a lot for the patch. I can also reproduce this but apparently it run smoothly on the Jenkins build servers, so I'm not really sure why it hangs there. Perhaps someone else has a better idea? > make check hangs on TSocket tests in TransportTest.cpp > -- > > Key: THRIFT-1850 > URL: https://issues.apache.org/jira/browse/THRIFT-1850 > Project: Thrift > Issue Type: Bug > Components: Test Suite >Affects Versions: 0.9, 1.0 > Environment: Mint 14 x64 and Centos 6.3 x64 and x86 [Web Server > Profile] with clean install and minimum Thrift support added for C++ >Reporter: Randy Abernethy > Fix For: 1.0 > > Attachments: 0001-TSocket-TransportTest.cpp-hang.patch > > > On the systems noted with trunk rev 3a67c2f >TEST_BLOCKING_BEHAVIOR(CoupledFDTransports) and >TEST_BLOCKING_BEHAVIOR(CoupledSocketTransports) in >lib/cpp/test/TransportTest.cpp (around line 850) > produce timeout alarms with the warning: >"Timeout alarm expired; attempting to unblock transport" > and then the 4th (and 8th) TEST_RW(CoupledSocketTransports,...) hangs > indefinitely due to a blocking socket write. Some others have noticed this: >http://stackoverflow.com/questions/13147105/thrfit-make-check-stuck > I have attached a patch that sets a timeout on the TSocket in question > allowing transport reads to take place when the socket layer refuses to > write. It appears trunk revision 0c025e8f reduced the socket_max_outstanding > on the two problem tests to 400 in order to repair this (which I assume it > did at the time). I do not think this is needed with the attached patch and > have reverted to the symbolic socket_max_outstanding value. > The two TEST_BLOCKING_BEHAVIOR timeouts still alarm but the tests appear to > run as they were meant to with this patch on all three systems I have tested. > This is my first contribution, please let me know if it is off base in any > way. -- 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] (THRIFT-1853) Error when leaving struct field null in Client
[ https://issues.apache.org/jira/browse/THRIFT-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13637841#comment-13637841 ] Henrique Mendonca commented on THRIFT-1853: --- Hi Nick, Do you have any updates on this? If you have any unit-test for this please also attach it here. Thank you, Henrique > Error when leaving struct field null in Client > -- > > Key: THRIFT-1853 > URL: https://issues.apache.org/jira/browse/THRIFT-1853 > Project: Thrift > Issue Type: Bug > Components: Node.js - Library >Reporter: Nick Daugherty > > When sending a struct over the wire from the client, the following error is > produced if one or more struct fields are left void or set to null, even if > marked as optional in the definition. > I figure the buf from transport.js ~line 119 is null when that field hasn't > been set, hence the 'has no method "copy"' error. > Object # has no method 'copy'","name":"TypeError","stack":"TypeError: > Object # has no method 'copy' > at node_modules/thrift/lib/thrift/transport.js:119:17 > at Array.forEach (native) > at Object.TFramedTransport.flush > (node_modules/thrift/lib/thrift/transport.js:118:21) > at Object.MyServiceClient.send_myMethod > (thrift/gen-nodejs/MyService.js:873:22) > at Object.TimersServiceClient.myMethod (thrift/gen-nodejs/MyService.js:855:8) -- 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] (THRIFT-1871) Better null-safe handling
[
https://issues.apache.org/jira/browse/THRIFT-1871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13624899#comment-13624899
]
Henrique Mendonca commented on THRIFT-1871:
---
Hi Eirik, sorry for the delay again
I think your "scenario2" seems to be quite feasible for now.
Since it would involve only changes on the Java compiler, I'd advise you to
open a separated ticket for that so the guys working with the Java library can
also give their opinion.
Thank you for sharing your ideas.
ps: Can you not solve that with the normal primitive wrappers, e.g.
java.lang.Integer ?? but I leave that to you guys to discuss and decide.
> Better null-safe handling
> -
>
> Key: THRIFT-1871
> URL: https://issues.apache.org/jira/browse/THRIFT-1871
> Project: Thrift
> Issue Type: Brainstorming
> Components: Compiler (General)
>Reporter: Eirik Sletteberg
> Attachments: Add_nullable_modifier_to_functions.patch
>
>
> Optional fields are not really handled well, especially in java clients.
> (NullPointerExceptions everywhere)
> Scrooge (Twitter's alternative Thrift compiler implementation) solves this
> problem by wrapping all optional fields in an Option class. Could this be
> implemented in Thrift?
> As of today, services have no way of returning empty results; for example
> UserService {
> 1: User getUser(1: i32 id)
> }
> cannot return an empty user if the ID is not found.
> There are a few ways to solve this:
> UserService {
> 1: User getUser(1: i32 id) throws UserNotFoundException
> }
> -- or --
> UserService {
> 1: List getUser(1: i32 id)
> }
> where an empty list is returned of no user is found, and a list containing
> one item is returned if a user is found.
> -- or --
> UserResult {
> 1: bool exists;
> 2: User user;
> }
> UserService {
> 1: UserResult getUser(1: i32 id)
> }
> I don't like any of them.
> One could solve this by letting the "optional" keyword apply to methods:
> UserService {
> 1: optional User getUser(1: i32 id)
> }
> or adding a new type to the IDL; the Option type:
> UserService {
> 1: Option getUser(1: i32 id)
> }
> and then, like Scrooge does, generate code that wraps the optional fields in
> an "Option" type, which is null-safe.
> The Option type could also be used in structs:
> struct User {
> 1: i32 id;
> 2: string name;
> 3: optional string email;
> }
> -- or --
> struct User {
> 1: i32 id;
> 2: string name;
> 3: Option email;
> }
> Either way, a null-safe Option wrapper would be used in the generated java
> code.
--
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] (THRIFT-1871) Better null-safe handling
[
https://issues.apache.org/jira/browse/THRIFT-1871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13600467#comment-13600467
]
Henrique Mendonca commented on THRIFT-1871:
---
Hi Eirik,
That's an interesting suggestion, but could the protocols handle these optional
results? And how would you implement this for all other target languages?
I also wish we had smart pointers on the c++ library, instead of empty objects,
but this would be also kind of a lot of work for now.
Moreover, I don't really see what's the big deal of using either exceptions or
optional fields to handle your example.
Thrift has its limitations but it also has many strengths ;)
> Better null-safe handling
> -
>
> Key: THRIFT-1871
> URL: https://issues.apache.org/jira/browse/THRIFT-1871
> Project: Thrift
> Issue Type: Brainstorming
> Components: Compiler (General)
>Reporter: Eirik Sletteberg
> Attachments: Add_nullable_modifier_to_functions.patch
>
>
> Optional fields are not really handled well, especially in java clients.
> (NullPointerExceptions everywhere)
> Scrooge (Twitter's alternative Thrift compiler implementation) solves this
> problem by wrapping all optional fields in an Option class. Could this be
> implemented in Thrift?
> As of today, services have no way of returning empty results; for example
> UserService {
> 1: User getUser(1: i32 id)
> }
> cannot return an empty user if the ID is not found.
> There are a few ways to solve this:
> UserService {
> 1: User getUser(1: i32 id) throws UserNotFoundException
> }
> -- or --
> UserService {
> 1: List getUser(1: i32 id)
> }
> where an empty list is returned of no user is found, and a list containing
> one item is returned if a user is found.
> -- or --
> UserResult {
> 1: bool exists;
> 2: User user;
> }
> UserService {
> 1: UserResult getUser(1: i32 id)
> }
> I don't like any of them.
> One could solve this by letting the "optional" keyword apply to methods:
> UserService {
> 1: optional User getUser(1: i32 id)
> }
> or adding a new type to the IDL; the Option type:
> UserService {
> 1: Option getUser(1: i32 id)
> }
> and then, like Scrooge does, generate code that wraps the optional fields in
> an "Option" type, which is null-safe.
> The Option type could also be used in structs:
> struct User {
> 1: i32 id;
> 2: string name;
> 3: optional string email;
> }
> -- or --
> struct User {
> 1: i32 id;
> 2: string name;
> 3: Option email;
> }
> Either way, a null-safe Option wrapper would be used in the generated java
> code.
--
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] [Closed] (THRIFT-1865) Thrift don't build on Android
[ https://issues.apache.org/jira/browse/THRIFT-1865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henrique Mendonca closed THRIFT-1865. - Resolution: Duplicate Thanks Ben > Thrift don't build on Android > - > > Key: THRIFT-1865 > URL: https://issues.apache.org/jira/browse/THRIFT-1865 > Project: Thrift > Issue Type: Bug > Components: C++ - Library >Affects Versions: 1.0 > Environment: Debian Gnu/linux, using Android NDK r8d. >Reporter: David >Priority: Critical > Labels: c++ > > Cross-compiling Thrift development version to Android give me the following > error: > ""In file included from > /android-ndk-r8d/platforms/android-9/arch-arm/usr/include/sys/un.h:31:0, > from /thrift/lib/cpp/src/thrift/transport/TSocket.cpp:26: > /android-ndk-r8d/platforms/android-9/arch-arm/usr/include/linux/un.h:18:2: > error: 'sa_family_t' does not name a type > /thrift/lib/cpp/src/thrift/transport/TSocket.cpp: In member function 'void > apache::thrift::transport::TSocket::openConnection(addrinfo*)': > /thrift/lib/cpp/src/thrift/transport/TSocket.cpp:250:13: error: 'struct > sockaddr_un' has no member named 'sun_family' > make[1]: *** > [obj/local/armeabi/objs/thrift-static/src/thrift/transport/TSocket.o] Error > 1"" > Looking throught the git repository I found this commit: "THRIFT-1740 Make > C++ library build on OS X and iOS". > It removes the import 'sys/socket.h' from socket.ccp needed by the struct > 'sockaddr_un'. The problems arises because on some kernels versions the > header 'linux/un.h' didn't include 'linux/socket.h' and didnt have > sa_family_t defined. -- 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] [Closed] (THRIFT-1862) Java thrift generated coe: default constructor initialize fields with default values but doesn't set their isSet flags
[
https://issues.apache.org/jira/browse/THRIFT-1862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henrique Mendonca closed THRIFT-1862.
-
> Java thrift generated coe: default constructor initialize fields with default
> values but doesn't set their isSet flags
> --
>
> Key: THRIFT-1862
> URL: https://issues.apache.org/jira/browse/THRIFT-1862
> Project: Thrift
> Issue Type: Bug
> Components: Java - Compiler
>Affects Versions: 0.5
> Environment: Mac
>Reporter: Jin Feng
>Priority: Minor
>
> I have thrift:
> {code}
> const i16 CURRENT_VERSION = 10;
> struct SomeMsg {
> 1: optional i16 currentVersion = CURRENT_VERSION;
> }
> {code}
> Now, when the follow test will fail:
> {code}
> SomeMsg msg = new SomeMsg();
> assertEquals(Constants.CURRENT_VESRION, msg.getCurrentVersion()); // pass
> assertTrue(msg.isSetCurrentVersion()); // fail.
> {code}
> Question is: is this behavior by design?
--
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] [Resolved] (THRIFT-1862) Java thrift generated coe: default constructor initialize fields with default values but doesn't set their isSet flags
[
https://issues.apache.org/jira/browse/THRIFT-1862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henrique Mendonca resolved THRIFT-1862.
---
Resolution: Duplicate
> Java thrift generated coe: default constructor initialize fields with default
> values but doesn't set their isSet flags
> --
>
> Key: THRIFT-1862
> URL: https://issues.apache.org/jira/browse/THRIFT-1862
> Project: Thrift
> Issue Type: Bug
> Components: Java - Compiler
>Affects Versions: 0.5
> Environment: Mac
>Reporter: Jin Feng
>Priority: Minor
>
> I have thrift:
> {code}
> const i16 CURRENT_VERSION = 10;
> struct SomeMsg {
> 1: optional i16 currentVersion = CURRENT_VERSION;
> }
> {code}
> Now, when the follow test will fail:
> {code}
> SomeMsg msg = new SomeMsg();
> assertEquals(Constants.CURRENT_VESRION, msg.getCurrentVersion()); // pass
> assertTrue(msg.isSetCurrentVersion()); // fail.
> {code}
> Question is: is this behavior by design?
--
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] (THRIFT-1833) Thrift generates incorrect C++ writer for union
[ https://issues.apache.org/jira/browse/THRIFT-1833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13579470#comment-13579470 ] Henrique Mendonca commented on THRIFT-1833: --- Hi Alan, there is also the cross language test: thrift/test/test.sh Cheers, Henrique > Thrift generates incorrect C++ writer for union > --- > > Key: THRIFT-1833 > URL: https://issues.apache.org/jira/browse/THRIFT-1833 > Project: Thrift > Issue Type: Bug > Components: C++ - Compiler >Affects Versions: 0.9 >Reporter: Alan Choi > Attachments: Thrift-1833.diff > > > The generated union struct c++ writer would write all union fields. This is > incorrect. It should only write the field that has been set. > It causes incompatibility between c++ and Java. A union written by C++ side > cannot be read by the Java side. -- 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] (THRIFT-1841) NodeJS Thrift incorrectly parses non-UTF8-string types
[
https://issues.apache.org/jira/browse/THRIFT-1841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13561595#comment-13561595
]
Henrique Mendonca commented on THRIFT-1841:
---
Hi Nabeel,
Thanks for reporting this. There are some known bugs on the Node.js library and
we'd be really interested on a patch
http://thrift.apache.org/docs/HowToContribute/
You can use the unit-tests and test.sh as reference, further test cases are
also welcome ;)
Cheers,
Henrique
> NodeJS Thrift incorrectly parses non-UTF8-string types
> --
>
> Key: THRIFT-1841
> URL: https://issues.apache.org/jira/browse/THRIFT-1841
> Project: Thrift
> Issue Type: Bug
> Components: Node.js - Compiler, Node.js - Library
>Affects Versions: 0.9, 1.0
>Reporter: Nabeel Shahzad
>
> **Edit**: See my comment below.
> When a double/float is used in a map (key or value), list, or set types, the
> decoding is done as a utf8 string, which then incorrectly parses and adds
> extra bytes.
> For example:
> The bytes of a map (this is coming out of the Thrift call)
> {noformat}
> 00 01 00 08 3f f4 00 00 00 00 00 00 00 08 40 02 00 00 00 00 00 00
> {noformat}
> But after it's been parsed out from the field as UTF8:
> {noformat}
> 00 01 00 08 3f 3f 00 00 00 00 00 00 00 08 40 02 00 00 00 00 00 00
> {noformat}
> As you can see there's an incorrect byte (the 3f where the f4, and an extra
> 00). For reference, this value was map = {1.25: 2.25}. This
> is the same behavior for floats. The f4 translated to ASCII 247, which I
> believe isn't a valid utf8 code.
> The actual value of the field becomes:
> {noformat}
> value:
> '\u\u0002\u\b??\u\u\u\u\u\u\u\b@\u0002\u\u\u\u\u\u''
> {noformat}
> Where the \b = 8, ? = f4, ? = unknown char.
> I have seen cases where there are *extra* bytes added in, which breaks the
> parsing based on byte size:
> {noformat}
> 00 01 00 08 40 24 48 72 c2 b0 20 c3 84 c2 9c 00 08 40 34 c3 bc c3 93 5a c2 85
> c2 87 c2 94
> {noformat}
> Where the MAP value was {10.1415, 20.9876}. On a list or set, using either
> value also yields extra bytes.
> So this messes up any parsing based on the byte-length for the field, since
> there are a variable number of extra bytes added, either to the key or value
> of the map, and any values of a list. I believe this could also happen on
> high-integer values.
> It seems to me when the "ftype" is parsed (int16) before the actual field,
> it's returning a TYPE value of "11" (string) - instead of the proper value of
> a map/set/list.
> For reference, the table, and an insert example:
> {noformat}
> CREATE TABLE sample_map (
> id text PRIMARY KEY,
> map_col_text map < text, text >,
> map_col_int map < int, text >,
> map_col_float map < float, float >,
> map_col_double map < double, double >
> );
> INSERT INTO sample_map (id, map_col_double) VALUES('DOUBLE_ROW_SINGLE',
> {10.1415: 20.9876});
> {noformat}
> Not sure if it matters, but this was using CQL3. Also, we are not seeing this
> on the C++ generated Thrift interface.
> Versions:
> {noformat}
> cqlsh:orion> show version;
> [cqlsh 2.3.0 | Cassandra 1.2.0 | CQL spec 3.0.0 | Thrift protocol 19.35.0]
> {noformat}
> {noformat}
> $ thrift --version
> Thrift version 0.9.0
> {noformat}
> {noformat}
> "name": "node-thrift",
> "description": "node.js bindings for the Apache Thrift RPC system",
> "homepage": "http://thrift.apache.org/";,
> "repository": {
> "type": "svn",
> "url": "http://svn.apache.org/repos/asf/thrift/trunk/";
> },
> "version": "1.0.0-dev",
> {noformat}
> The issue also appears in the 0.9.0 version of the thrift library.
--
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] (THRIFT-1804) Binary+compact protocol byte corruption in Ruby library (ARM architecture)
[
https://issues.apache.org/jira/browse/THRIFT-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13550380#comment-13550380
]
Henrique Mendonca commented on THRIFT-1804:
---
Hi Elias,
This is kind of weird, the type byte is normally unsigned and I think the C++
compiler uses a uint8_t for it.
Unfortunately it doesn't get properly tested on ./test/cpp/src/TestClient.cpp,
so we can't be sure it works on every platform either.
Although, I guess it won't help much, you should be actually testing with 0-255.
> Binary+compact protocol byte corruption in Ruby library (ARM architecture)
> --
>
> Key: THRIFT-1804
> URL: https://issues.apache.org/jira/browse/THRIFT-1804
> Project: Thrift
> Issue Type: Bug
> Components: Build Process
>Affects Versions: 0.9
> Environment: - Debian/ARM Squeeze 6.0.6 native armv5te, compiler: gcc
> (Debian 4.4.5-8) 4.4.5
> QEMU emulated debian hosts:
> - Debian Squeeze 6.0.6 emulated armvtejl, compiler: gcc (Debian 4.4.5-8)
> - Debian Sid 7.0 on QEMU ARM versatilepb, compiler: gcc (Debian 4.6.3-14)
>Reporter: Elias Karakoulakis
>
> These compilation tests fail when compiling for ARM:
> 1) BinaryProtocolAccelerated it should behave like a binary protocol should
> read a byte
> Failure/Error: @prot.read_byte.should == i
>{*}expected: -128{*}
> {*}got: 128 (using ==){*}
> Shared Example Group: "a binary protocol" called from
> ./spec/binary_protocol_accelerated_spec.rb:28
> # ./spec/binary_protocol_spec_shared.rb:291:in `block (3 levels) in (required)>'
> # ./spec/binary_protocol_spec_shared.rb:289:in `each'
> # ./spec/binary_protocol_spec_shared.rb:289:in `block (2 levels) in (required)>'
> 2) BinaryProtocolAccelerated it should behave like a binary protocol should
> perform a complete rpc with a struct return type
> Failure/Error: result.should == Fixtures::COMPACT_PROTOCOL_TEST_STRUCT
>expected: 127]{*},
> got: 127]{*}, ... (using ==)
> (***) only byte_list gets corrupted
> Shared Example Group: "a binary protocol" called from
> ./spec/binary_protocol_accelerated_spec.rb:28
> # ./spec/binary_protocol_spec_shared.rb:375:in `block (3 levels) in (required)>'
> # ./spec/binary_protocol_spec_shared.rb:406:in `call'
> # ./spec/binary_protocol_spec_shared.rb:406:in `srv_test'
> # ./spec/binary_protocol_spec_shared.rb:370:in `block (2 levels) in (required)>'
> 3) Thrift::CompactProtocol should encode and decode naked primitives
> correctly
> Failure/Error: read_back.should == value
>{*}expected: -127{*}
> {*}got: 129 (using ==){*}
> # ./spec/compact_protocol_spec.rb:45:in `block (4 levels) in (required)>'
> # ./spec/compact_protocol_spec.rb:37:in `each'
> # ./spec/compact_protocol_spec.rb:37:in `block (3 levels) in (required)>'
> # ./spec/compact_protocol_spec.rb:36:in `each_pair'
> # ./spec/compact_protocol_spec.rb:36:in `block (2 levels) in (required)>'
> 4) Thrift::CompactProtocol should encode and decode primitives in fields
> correctly
> Failure/Error: read_back.should == value
>{*}expected: -127{*}
> {*}got: 129 (using ==){*}
> # ./spec/compact_protocol_spec.rb:68:in `block (4 levels) in (required)>'
> # ./spec/compact_protocol_spec.rb:55:in `each'
> # ./spec/compact_protocol_spec.rb:55:in `block (3 levels) in (required)>'
> # ./spec/compact_protocol_spec.rb:51:in `each_pair'
> # ./spec/compact_protocol_spec.rb:51:in `block (2 levels) in (required)>'
> Finished in 5.87 seconds
> 364 examples, 4 failures, 1 pending
--
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] (THRIFT-1816) Need "require" included thrift files in "xxx_types.js"
[
https://issues.apache.org/jira/browse/THRIFT-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13549893#comment-13549893
]
Henrique Mendonca commented on THRIFT-1816:
---
+1
@Roger: should we add a test include to ThriftTest.thrift?
e.g.:
struct IncludedStruct {
1: ThriftTestInc.TestStruct inc;
}
> Need "require" included thrift files in "xxx_types.js"
> --
>
> Key: THRIFT-1816
> URL: https://issues.apache.org/jira/browse/THRIFT-1816
> Project: Thrift
> Issue Type: Bug
> Components: Node.js - Compiler
>Reporter: Chao Shi
> Attachments: thrift-1816.patch
>
>
> Currently the compiler for nodejs only generate require statement in each
> service js. It is also needed in the "types" js. I have a patch for this.
--
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] (THRIFT-1772) Serialization does not check types of embedded structures.
[
https://issues.apache.org/jira/browse/THRIFT-1772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13532603#comment-13532603
]
Henrique Mendonca commented on THRIFT-1772:
---
Hi Avi,
Sorry for the delay.
Can you please submit the patch so others can have a look?
Our resources are also very limited, but we can see what we can do ;)
Cheers
> Serialization does not check types of embedded structures.
> --
>
> Key: THRIFT-1772
> URL: https://issues.apache.org/jira/browse/THRIFT-1772
> Project: Thrift
> Issue Type: Bug
> Components: Python - Library
>Affects Versions: 0.8, 0.9
>Reporter: Avi Flamholz
>
> Consider the following struct definitions:
> struct Point {
> 1: required double x;
> 2: required double y;
> }
> struct Review {
> 1: required i32 rating;
> 2: optional string text;
> }
> struct Place {
> 1: required string name;
> 2: required Point location;
> 3: optional Review review;
> }
> If I create a Place object and set the location field to a Review, it will
> serialize no problem.
> place = Place(name="avi's place", location=Review(rating=1.0))
> transportOut = TTransport.TMemoryBuffer()
> protocolOut = TBinaryProtocol.TBinaryProtocol(transportOut)
> place.write(protocolOut)
> serialized = transportOut.getvalue()
> This is confusing because if I set an i32 field to a string serialization
> does raise an error.
--
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] (THRIFT-1782) async only defined in silverlight
[ https://issues.apache.org/jira/browse/THRIFT-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13527527#comment-13527527 ] Henrique Mendonca commented on THRIFT-1782: --- but yeah, async await is awesome! :) > async only defined in silverlight > - > > Key: THRIFT-1782 > URL: https://issues.apache.org/jira/browse/THRIFT-1782 > Project: Thrift > Issue Type: Bug > Components: C# - Compiler >Affects Versions: 0.9 >Reporter: Carl Yeksigian > Fix For: 1.0 > > Attachments: 1782.txt > > > The async pattern is available in C# 5 on .NET 4.5. Thus, it shouldn't only > be for Silverlight. -- 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] (THRIFT-1782) async only defined in silverlight
[ https://issues.apache.org/jira/browse/THRIFT-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13527526#comment-13527526 ] Henrique Mendonca commented on THRIFT-1782: --- Sure guys, I agree with you that we should keep thrift updated with the latest improvements of the framework. I could not find any documentation on which framework version we target but in my opinion we should at least support 4 or 3.5 as well (+ Mono for linux). Anyway, the "async" keyword does not do the same as the SILVERLIGHT pre-processor variable, I think it is meant only for the CTP support, and I saw before many more references to SILVERLIGHT in the code enabling the async functions, not only that one you propose to remove. I think this is an improvement and we should eventually get it to the trunk, but we do have to work a little more on it. Thanks heaps again! > async only defined in silverlight > - > > Key: THRIFT-1782 > URL: https://issues.apache.org/jira/browse/THRIFT-1782 > Project: Thrift > Issue Type: Bug > Components: C# - Compiler >Affects Versions: 0.9 >Reporter: Carl Yeksigian > Fix For: 1.0 > > Attachments: 1782.txt > > > The async pattern is available in C# 5 on .NET 4.5. Thus, it shouldn't only > be for Silverlight. -- 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] (THRIFT-1782) async only defined in silverlight
[ https://issues.apache.org/jira/browse/THRIFT-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13527400#comment-13527400 ] Henrique Mendonca commented on THRIFT-1782: --- Hi Carl, Thanks for the patch, should we check the version instead then? It'd be nice if we keep the legacy compatibility. This should work with the newest version, silverlight, but also with older versions of the framework, not to forget the mono framework ;) Cheers, Henrique > async only defined in silverlight > - > > Key: THRIFT-1782 > URL: https://issues.apache.org/jira/browse/THRIFT-1782 > Project: Thrift > Issue Type: Bug > Components: C# - Compiler >Affects Versions: 0.9 >Reporter: Carl Yeksigian > Fix For: 1.0 > > Attachments: 1782.txt > > > The async pattern is available in C# 5 on .NET 4.5. Thus, it shouldn't only > be for Silverlight. -- 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] (THRIFT-1772) Serialization does not check types of embedded structures.
[
https://issues.apache.org/jira/browse/THRIFT-1772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509987#comment-13509987
]
Henrique Mendonca commented on THRIFT-1772:
---
Thanks Avi, Although it might reduce performance, I think we should consider
also checking the object type.
Do you want to send us a patch?
Please see http://wiki.apache.org/thrift/HowToContribute
Moreover, this probably affects the JS lib too, no sure about php and other
weakly-typed languages... Can anyone help us?
Cheers,
Henrique
> Serialization does not check types of embedded structures.
> --
>
> Key: THRIFT-1772
> URL: https://issues.apache.org/jira/browse/THRIFT-1772
> Project: Thrift
> Issue Type: Bug
> Components: Python - Library
>Affects Versions: 0.8, 0.9
>Reporter: Avi Flamholz
>
> Consider the following struct definitions:
> struct Point {
> 1: required double x;
> 2: required double y;
> }
> struct Review {
> 1: required i32 rating;
> 2: optional string text;
> }
> struct Place {
> 1: required string name;
> 2: required Point location;
> 3: optional Review review;
> }
> If I create a Place object and set the location field to a Review, it will
> serialize no problem.
> place = Place(name="avi's place", location=Review(rating=1.0))
> transportOut = TTransport.TMemoryBuffer()
> protocolOut = TBinaryProtocol.TBinaryProtocol(transportOut)
> place.write(protocolOut)
> serialized = transportOut.getvalue()
> This is confusing because if I set an i32 field to a string serialization
> does raise an error.
--
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] (THRIFT-1761) Make generated exceptions have a common unique parent
[ https://issues.apache.org/jira/browse/THRIFT-1761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13506675#comment-13506675 ] Henrique Mendonca commented on THRIFT-1761: --- I see your point, it kind of increases the complexity of the things, specially when there is already some synchronisation problem between the different libs, but I'd be probably OK if it. However, I believe those classes should be in reality abstract classes. Anyway, I looking forward to hear someone else's opinion here too. Cheers, Henrique > Make generated exceptions have a common unique parent > - > > Key: THRIFT-1761 > URL: https://issues.apache.org/jira/browse/THRIFT-1761 > Project: Thrift > Issue Type: Improvement >Reporter: Nathaniel Cook > Labels: exception-handling, exceptions > Attachments: thrift-1761_php_py_java_cpp_js.patch > > > It would be nice to be able to have exceptions that are thrown by services be > caught independently of other thrift exceptions. Currently generated > exceptions extend TException directly. They should extend a TServiceException > which in turn extends TException. This would allow client code to catch all > exceptions thrown by the service without catching exceptions related to the > actual thrift communication layer -- 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] (THRIFT-1767) unions can't have required fields
[ https://issues.apache.org/jira/browse/THRIFT-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13506276#comment-13506276 ] Henrique Mendonca commented on THRIFT-1767: --- +1, thanks Jens! ... but shouldn't we throw a warning, at least, when compiling the idl? > unions can't have required fields > -- > > Key: THRIFT-1767 > URL: https://issues.apache.org/jira/browse/THRIFT-1767 > Project: Thrift > Issue Type: Bug > Components: Delphi - Compiler >Affects Versions: 0.8, 0.9 >Reporter: Jens Geyer >Assignee: Jens Geyer > Fix For: 1.0 > > Attachments: THRIFT-1767_unions_cant_have_required_fields.patch > > > Required fields within unions should be treaten as optional, the union > construct would not make much sense otherwise. -- 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] [Closed] (THRIFT-1758) bad_lexical_cast using TJSONProtocol
[
https://issues.apache.org/jira/browse/THRIFT-1758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henrique Mendonca closed THRIFT-1758.
-
> bad_lexical_cast using TJSONProtocol
>
>
> Key: THRIFT-1758
> URL: https://issues.apache.org/jira/browse/THRIFT-1758
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
>Affects Versions: 0.9
> Environment: boost 1.52.0
> iOS 6.0
>Reporter: Vitali Lovich
>Priority: Critical
>
> try{
> std::string str("-0.003024283066062361");
> double d = boost::lexical_cast(str);
> // bad_lexical_cast is thrown
> } catch (const boost::bad_lexical_cast& e) {
> std::cerr << e.what() << std::endl;
> }
> bad_lexical_cast is thrown. This is a problem for TJSONProtocol which relies
> on lexical_cast handling this properly.
> Looking through the code, it looks to have to do something with the
> compile-time precision.
> defining BOOST_LCAST_NO_COMPILE_TIME_PRECISION appears to resolve this issue
> (potentially at the cost of performance?).
> this problem also doesn't appear to happen all the time with the same input
> data. sometime's it's reproducible every time, other times it isn't.
--
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] [Resolved] (THRIFT-1758) bad_lexical_cast using TJSONProtocol
[
https://issues.apache.org/jira/browse/THRIFT-1758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henrique Mendonca resolved THRIFT-1758.
---
Resolution: Cannot Reproduce
Hi Vitali,
I cannot reproduce your exception on boost 1.43.0, neither on x86 nor on ARM,
which boost version are you using?
I think the correct resolution here would be to throw an TApplication exception
back to the client, please let's us know if you have a working patch.
Cheers,
Henrique
> bad_lexical_cast using TJSONProtocol
>
>
> Key: THRIFT-1758
> URL: https://issues.apache.org/jira/browse/THRIFT-1758
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
>Affects Versions: 0.9
> Environment: boost 1.52.0
> iOS 6.0
>Reporter: Vitali Lovich
>Priority: Critical
>
> try{
> std::string str("-0.003024283066062361");
> double d = boost::lexical_cast(str);
> // bad_lexical_cast is thrown
> } catch (const boost::bad_lexical_cast& e) {
> std::cerr << e.what() << std::endl;
> }
> bad_lexical_cast is thrown. This is a problem for TJSONProtocol which relies
> on lexical_cast handling this properly.
> Looking through the code, it looks to have to do something with the
> compile-time precision.
> defining BOOST_LCAST_NO_COMPILE_TIME_PRECISION appears to resolve this issue
> (potentially at the cost of performance?).
> this problem also doesn't appear to happen all the time with the same input
> data. sometime's it's reproducible every time, other times it isn't.
--
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] (THRIFT-1758) bad_lexical_cast using TJSONProtocol
[
https://issues.apache.org/jira/browse/THRIFT-1758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henrique Mendonca updated THRIFT-1758:
--
Description:
try{
std::string str("-0.003024283066062361");
double d = boost::lexical_cast(str);
// bad_lexical_cast is thrown
} catch (const boost::bad_lexical_cast& e) {
std::cerr << e.what() << std::endl;
}
bad_lexical_cast is thrown. This is a problem for TJSONProtocol which relies
on lexical_cast handling this properly.
Looking through the code, it looks to have to do something with the
compile-time precision.
defining BOOST_LCAST_NO_COMPILE_TIME_PRECISION appears to resolve this issue
(potentially at the cost of performance?).
this problem also doesn't appear to happen all the time with the same input
data. sometime's it's reproducible every time, other times it isn't.
was:
try{
std::string str("-0.003024283066062361")
double d = boost::lexical_cast(str);
// bad_lexical_cast is thrown
} catch (const boost::bad_lexical_cast& e) {
std::cerr << e.what() << std::endl;
}
bad_lexical_cast is thrown. This is a problem for TJSONProtocol which relies
on lexical_cast handling this properly.
Looking through the code, it looks to have to do something with the
compile-time precision.
defining BOOST_LCAST_NO_COMPILE_TIME_PRECISION appears to resolve this issue
(potentially at the cost of performance?).
this problem also doesn't appear to happen all the time with the same input
data. sometime's it's reproducible every time, other times it isn't.
> bad_lexical_cast using TJSONProtocol
>
>
> Key: THRIFT-1758
> URL: https://issues.apache.org/jira/browse/THRIFT-1758
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
>Affects Versions: 0.9
> Environment: boost 1.52.0
> iOS 6.0
>Reporter: Vitali Lovich
>Priority: Critical
>
> try{
> std::string str("-0.003024283066062361");
> double d = boost::lexical_cast(str);
> // bad_lexical_cast is thrown
> } catch (const boost::bad_lexical_cast& e) {
> std::cerr << e.what() << std::endl;
> }
> bad_lexical_cast is thrown. This is a problem for TJSONProtocol which relies
> on lexical_cast handling this properly.
> Looking through the code, it looks to have to do something with the
> compile-time precision.
> defining BOOST_LCAST_NO_COMPILE_TIME_PRECISION appears to resolve this issue
> (potentially at the cost of performance?).
> this problem also doesn't appear to happen all the time with the same input
> data. sometime's it's reproducible every time, other times it isn't.
--
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] [Closed] (THRIFT-1706) jquery ajax code doesn't handle exceptions
[ https://issues.apache.org/jira/browse/THRIFT-1706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henrique Mendonca closed THRIFT-1706. - Resolution: Not A Problem Please, feel free to re-open it if you find something else or have a patch for the improvement. Cheers, Henrique > jquery ajax code doesn't handle exceptions > -- > > Key: THRIFT-1706 > URL: https://issues.apache.org/jira/browse/THRIFT-1706 > Project: Thrift > Issue Type: Bug > Components: JavaScript - Library >Affects Versions: 0.9 >Reporter: Kevin Radloff > > The converter function inside of the jquery ajax handler makes no > accommodations for exceptions that may be thrown during the normal course of > running "recv_method.call()" for a remote method that raises an exception. If > this happens, the result gets lost as the normal ajax response handling is > aborted. > It seems like the converter function should at the very least have a > try/catch block that sets the exception as the ajax result in the place of a > regular thrift type/object. It might be best to have some sort of interface > that takes both a callback and errback, however, so as to not require > introspection into the result. -- 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] (THRIFT-1706) jquery ajax code doesn't handle exceptions
[ https://issues.apache.org/jira/browse/THRIFT-1706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13500597#comment-13500597 ] Henrique Mendonca commented on THRIFT-1706: --- Ah Ok, cross-domain is complicated! you might still be able to do it by requesting it manually: https://github.com/apache/thrift/blob/trunk/lib/js/test/test.js#L272 and using cross-origin resource sharing on latest browsers, you can google it but it's a little out of the scope here. Unless you want to integrate it as an optional thrift transport, which kind of sounds interesting! If you don't mind I'll close this ticket and you can use the mail list for further discussions. > jquery ajax code doesn't handle exceptions > -- > > Key: THRIFT-1706 > URL: https://issues.apache.org/jira/browse/THRIFT-1706 > Project: Thrift > Issue Type: Bug > Components: JavaScript - Library >Affects Versions: 0.9 >Reporter: Kevin Radloff > > The converter function inside of the jquery ajax handler makes no > accommodations for exceptions that may be thrown during the normal course of > running "recv_method.call()" for a remote method that raises an exception. If > this happens, the result gets lost as the normal ajax response handling is > aborted. > It seems like the converter function should at the very least have a > try/catch block that sets the exception as the ajax result in the place of a > regular thrift type/object. It might be best to have some sort of interface > that takes both a callback and errback, however, so as to not require > introspection into the result. -- 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] (THRIFT-1706) jquery ajax code doesn't handle exceptions
[ https://issues.apache.org/jira/browse/THRIFT-1706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13500564#comment-13500564 ] Henrique Mendonca commented on THRIFT-1706: --- "Normal" exceptions can be catch using the error() handler, please see: https://github.com/apache/thrift/blob/trunk/lib/js/test/test.js#L402 It that what you mean? it's similar to the jQuery AJAX mechanism... It's unfortunate it's not yet in the JS tutorial, but patches are always welcome ;) ps: no error or complete is called when nothing comes back, and this fix would be an improvement... > jquery ajax code doesn't handle exceptions > -- > > Key: THRIFT-1706 > URL: https://issues.apache.org/jira/browse/THRIFT-1706 > Project: Thrift > Issue Type: Bug > Components: JavaScript - Library >Affects Versions: 0.9 >Reporter: Kevin Radloff > > The converter function inside of the jquery ajax handler makes no > accommodations for exceptions that may be thrown during the normal course of > running "recv_method.call()" for a remote method that raises an exception. If > this happens, the result gets lost as the normal ajax response handling is > aborted. > It seems like the converter function should at the very least have a > try/catch block that sets the exception as the ajax result in the place of a > regular thrift type/object. It might be best to have some sort of interface > that takes both a callback and errback, however, so as to not require > introspection into the result. -- 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] (THRIFT-1706) jquery ajax code doesn't handle exceptions
[ https://issues.apache.org/jira/browse/THRIFT-1706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13500269#comment-13500269 ] Henrique Mendonca commented on THRIFT-1706: --- Cheers Øyvind. Would you guys have a test case for it? e.g. ideally a qunit test like on https://github.com/apache/thrift/blob/trunk/lib/js/test/test.js Perhaps if you send an argument of a wrong type you might be able to reproduce it... or do you have a different scenario? > jquery ajax code doesn't handle exceptions > -- > > Key: THRIFT-1706 > URL: https://issues.apache.org/jira/browse/THRIFT-1706 > Project: Thrift > Issue Type: Bug > Components: JavaScript - Library >Affects Versions: 0.9 >Reporter: Kevin Radloff > > The converter function inside of the jquery ajax handler makes no > accommodations for exceptions that may be thrown during the normal course of > running "recv_method.call()" for a remote method that raises an exception. If > this happens, the result gets lost as the normal ajax response handling is > aborted. > It seems like the converter function should at the very least have a > try/catch block that sets the exception as the ajax result in the place of a > regular thrift type/object. It might be best to have some sort of interface > that takes both a callback and errback, however, so as to not require > introspection into the result. -- 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] [Closed] (THRIFT-1744) Compilation failure under Android NDK toolchain
[ https://issues.apache.org/jira/browse/THRIFT-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henrique Mendonca closed THRIFT-1744. - Resolution: Fixed > Compilation failure under Android NDK toolchain > --- > > Key: THRIFT-1744 > URL: https://issues.apache.org/jira/browse/THRIFT-1744 > Project: Thrift > Issue Type: Bug > Components: C++ - Compiler >Affects Versions: 0.8 > Environment: Android NDK version: r8b > gcc version: 4.6 > Host system: Ubuntu 11.10 x64 >Reporter: Vlad Troyanker >Assignee: Henrique Mendonca > Labels: build, patch > Attachments: 0001-TSocketPool.cpp.patch > > > Using last stable Thrift release 0.8.0. After looking at the code I believe > the same problem exists at the top of dev branch. > Compiling Thrift C++ under Android NDK fails in transport/TSocketPool.cpp > because that file is missing include of config.h > Android NDK version: r8b > gcc version: 4.6 > Host system: Ubuntu 11.10 x64 -- 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] (THRIFT-1744) Compilation failure under Android NDK toolchain
[ https://issues.apache.org/jira/browse/THRIFT-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henrique Mendonca updated THRIFT-1744: -- Assignee: Henrique Mendonca > Compilation failure under Android NDK toolchain > --- > > Key: THRIFT-1744 > URL: https://issues.apache.org/jira/browse/THRIFT-1744 > Project: Thrift > Issue Type: Bug > Components: C++ - Compiler >Affects Versions: 0.8 > Environment: Android NDK version: r8b > gcc version: 4.6 > Host system: Ubuntu 11.10 x64 >Reporter: Vlad Troyanker >Assignee: Henrique Mendonca > Labels: build, patch > Attachments: 0001-TSocketPool.cpp.patch > > > Using last stable Thrift release 0.8.0. After looking at the code I believe > the same problem exists at the top of dev branch. > Compiling Thrift C++ under Android NDK fails in transport/TSocketPool.cpp > because that file is missing include of config.h > Android NDK version: r8b > gcc version: 4.6 > Host system: Ubuntu 11.10 x64 -- 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] [Closed] (THRIFT-1731) error: expected identifier before ‘;’ token
[ https://issues.apache.org/jira/browse/THRIFT-1731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henrique Mendonca closed THRIFT-1731. - > error: expected identifier before ‘;’ token > --- > > Key: THRIFT-1731 > URL: https://issues.apache.org/jira/browse/THRIFT-1731 > Project: Thrift > Issue Type: Bug > Components: C++ - Compiler >Affects Versions: 0.9 >Reporter: Martin Vogt >Assignee: Roger Meier >Priority: Trivial > Labels: empty, namespaces > Attachments: ns2.patch > > > If the .thrift file contains no namespace the cpp generator > creates a: > using namespace ; > line. This does not compile. -- 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] [Closed] (THRIFT-1730) error: ‘numeric_limits’ is not a member of ‘std’
[ https://issues.apache.org/jira/browse/THRIFT-1730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henrique Mendonca closed THRIFT-1730. - Assignee: Roger Meier > error: ‘numeric_limits’ is not a member of ‘std’ > > > Key: THRIFT-1730 > URL: https://issues.apache.org/jira/browse/THRIFT-1730 > Project: Thrift > Issue Type: Bug > Components: C++ - Library >Affects Versions: 0.9 > Environment: OpenSuSE 11.1 >Reporter: Martin Vogt >Assignee: Roger Meier >Priority: Trivial > Attachments: limits.patch > > > Compiler error with current git: > src/thrift/transport/THttpClient.cpp: In member function ‘virtual void > apache::thrift::transport::THttpClient::flush()’: > src/thrift/transport/THttpClient.cpp:104: error: ‘numeric_limits’ is not a > member of ‘std’ > src/thrift/transport/THttpClient.cpp:104: error: expected primary-expression > before ‘>’ token > src/thrift/transport/THttpClient.cpp:104: error: ‘::max’ has not been declared -- 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] [Closed] (THRIFT-1705) Unable to compile Thrift Enum in MSVC++
[ https://issues.apache.org/jira/browse/THRIFT-1705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henrique Mendonca closed THRIFT-1705. - > Unable to compile Thrift Enum in MSVC++ > --- > > Key: THRIFT-1705 > URL: https://issues.apache.org/jira/browse/THRIFT-1705 > Project: Thrift > Issue Type: Bug > Components: C++ - Library >Affects Versions: 0.8 >Reporter: Ryan Haswell > Labels: patch > Attachments: Thrift.h > > Original Estimate: 0h > Remaining Estimate: 0h > > Files generated by thrift files with an Enum in them will not compile using > Microsoft Visual Studio C++. -- 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] [Closed] (THRIFT-1713) Named and Anonymous Pipe transport (Delphi)
[ https://issues.apache.org/jira/browse/THRIFT-1713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henrique Mendonca closed THRIFT-1713. - > Named and Anonymous Pipe transport (Delphi) > --- > > Key: THRIFT-1713 > URL: https://issues.apache.org/jira/browse/THRIFT-1713 > Project: Thrift > Issue Type: Bug > Components: Delphi - Library > Environment: Windows >Reporter: Jens Geyer >Assignee: Jens Geyer > Fix For: 1.0 > > Attachments: > TRHIFT-1713_Named_and_Anonymous_Pipe_transport_Delphi_02_refactoring_rev3.patch, > TRHIFT-1713_Named_and_Anonymous_Pipe_transport_Delphi.patch > > > Adds pipe support similar to THRIFT-1558 (in fact, most of the code is based > on that version, many thanks Peace!). > The implementation has been successfully tested using the standard test > server/client, appropriate switches have been added to both programs. > However, the code has neither been tested against another language > implementation, nor under strict security settings for the pipes. -- 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] [Closed] (THRIFT-1414) bufferoverflow in c_glib buffered transport/socket client
[ https://issues.apache.org/jira/browse/THRIFT-1414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henrique Mendonca closed THRIFT-1414. - > bufferoverflow in c_glib buffered transport/socket client > - > > Key: THRIFT-1414 > URL: https://issues.apache.org/jira/browse/THRIFT-1414 > Project: Thrift > Issue Type: Bug > Components: C glib - Library >Affects Versions: 0.7 > Environment: Server running on Windows 7 SP1 64bit based on csharp. > Client running on Ubuntu 11.04 Server 64 bit (fresh install) based on c_glib. > svn rev: 1190015M >Reporter: Christian Zimnick >Priority: Critical > Attachments: thrift-0.9.0-c_glib-jira1414.patch, THRIFT-1414.patch > > Original Estimate: 10m > Remaining Estimate: 10m > > Quote of comment in source: > --- > if the buffer is still smaller than what we > want to read, then just read it directly. > --- > But the code reading into the tempdata with size of the buffer and reading > all data into this. > file: lib/c_glib/transport/thrift_buffered_transport.c line 74/98 > Also if the buffer is still bigger that what we want to read, then reading > the buffer size. > But recv blocks than and waiting of data if there nothing to read after the > receiving data len. > file: lib/c_glib/transport/thrift_buffered_transport.c line 118 > i attached a patch that fix this problems but i dont know if all of this is > correct. -- 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] [Closed] (THRIFT-1724) HTML generator doesn't identify unions in output
[ https://issues.apache.org/jira/browse/THRIFT-1724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henrique Mendonca closed THRIFT-1724. - > HTML generator doesn't identify unions in output > > > Key: THRIFT-1724 > URL: https://issues.apache.org/jira/browse/THRIFT-1724 > Project: Thrift > Issue Type: Bug > Components: Compiler (General) >Affects Versions: 0.8 >Reporter: Kevin Radloff >Assignee: Roger Meier >Priority: Minor > Attachments: html_union.diff > > > In the output of the HTML generator, unions appear identical to normal > structs. -- 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] [Closed] (THRIFT-1648) NodeJS clients always receive 0 for 'double' values.
[ https://issues.apache.org/jira/browse/THRIFT-1648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henrique Mendonca closed THRIFT-1648. - Resolution: Fixed Fix Version/s: 1.0 please see THRIFT-1353 > NodeJS clients always receive 0 for 'double' values. > > > Key: THRIFT-1648 > URL: https://issues.apache.org/jira/browse/THRIFT-1648 > Project: Thrift > Issue Type: Bug > Components: Node.js - Library >Affects Versions: 0.8 > Environment: Ubuntu 12.0.4; Client - NodeJS 0.6.x,0.8.0; Server - > Java 1.7; >Reporter: Dan Cromer > Fix For: 1.0 > > > During implementation of Apache Thrift <-> NodeJS, we discovered that NodeJS > clients always received a value of 0 for floats. We are using > BufferedTransport. I was unable to debug the issue. > The server was written in Java, and has a test suite working in Java. It > functions correctly, and receives the actual value for doubles. -- 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] [Closed] (THRIFT-1353) Switch to performance branch, get rid of BinaryParser
[ https://issues.apache.org/jira/browse/THRIFT-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henrique Mendonca closed THRIFT-1353. - > Switch to performance branch, get rid of BinaryParser > - > > Key: THRIFT-1353 > URL: https://issues.apache.org/jira/browse/THRIFT-1353 > Project: Thrift > Issue Type: Improvement > Components: Node.js - Library >Affects Versions: 0.7 >Reporter: Hans Duedal >Assignee: Henrique Mendonca > Labels: node, nodejs > Fix For: 1.0 > > Attachments: THRIFT-1353-noBinaryParser-BufferedTrans-Int64-v3.patch > > > I vote that the thrift library switches to the performance branch at > https://github.com/wadey/node-thrift/tree/performance > I much prefer using the node.js buffers over the BinaryParser class, the > performance branch seems focused on this very issue. Also it includes the > excellent int64 implementation from broofa. What's not to like? -- 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] [Resolved] (THRIFT-1353) Switch to performance branch, get rid of BinaryParser
[ https://issues.apache.org/jira/browse/THRIFT-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henrique Mendonca resolved THRIFT-1353. --- Resolution: Fixed Assignee: Henrique Mendonca (was: Roger Meier) finally committed! > Switch to performance branch, get rid of BinaryParser > - > > Key: THRIFT-1353 > URL: https://issues.apache.org/jira/browse/THRIFT-1353 > Project: Thrift > Issue Type: Improvement > Components: Node.js - Library >Affects Versions: 0.7 >Reporter: Hans Duedal >Assignee: Henrique Mendonca > Labels: node, nodejs > Fix For: 1.0 > > Attachments: THRIFT-1353-noBinaryParser-BufferedTrans-Int64-v3.patch > > > I vote that the thrift library switches to the performance branch at > https://github.com/wadey/node-thrift/tree/performance > I much prefer using the node.js buffers over the BinaryParser class, the > performance branch seems focused on this very issue. Also it includes the > excellent int64 implementation from broofa. What's not to like? -- 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] [Closed] (THRIFT-1738) node.js: export transport and protocol so they can be used outside the cassandra/server context
[ https://issues.apache.org/jira/browse/THRIFT-1738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henrique Mendonca closed THRIFT-1738. - Committed, thanks for the patch > node.js: export transport and protocol so they can be used outside the > cassandra/server context > > > Key: THRIFT-1738 > URL: https://issues.apache.org/jira/browse/THRIFT-1738 > Project: Thrift > Issue Type: Improvement > Components: Node.js - Library >Reporter: Barbara Raitz >Assignee: Henrique Mendonca > Attachments: thrift-export-transport-and-protocol-in-node.patch > > > I want to be able to serialize/de-serialize thrift-encoded data without > needing to create a cassandra/server connection. Exporting access to the > inner transport and protocol classes will enable that. -- 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] [Resolved] (THRIFT-1738) node.js: export transport and protocol so they can be used outside the cassandra/server context
[ https://issues.apache.org/jira/browse/THRIFT-1738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henrique Mendonca resolved THRIFT-1738. --- Resolution: Fixed > node.js: export transport and protocol so they can be used outside the > cassandra/server context > > > Key: THRIFT-1738 > URL: https://issues.apache.org/jira/browse/THRIFT-1738 > Project: Thrift > Issue Type: Improvement > Components: Node.js - Library >Reporter: Barbara Raitz >Assignee: Henrique Mendonca > Attachments: thrift-export-transport-and-protocol-in-node.patch > > > I want to be able to serialize/de-serialize thrift-encoded data without > needing to create a cassandra/server connection. Exporting access to the > inner transport and protocol classes will enable that. -- 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] (THRIFT-1738) node.js: export transport and protocol so they can be used outside the cassandra/server context
[ https://issues.apache.org/jira/browse/THRIFT-1738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henrique Mendonca updated THRIFT-1738: -- Assignee: Henrique Mendonca > node.js: export transport and protocol so they can be used outside the > cassandra/server context > > > Key: THRIFT-1738 > URL: https://issues.apache.org/jira/browse/THRIFT-1738 > Project: Thrift > Issue Type: Improvement > Components: Node.js - Library >Reporter: Barbara Raitz >Assignee: Henrique Mendonca > Attachments: thrift-export-transport-and-protocol-in-node.patch > > > I want to be able to serialize/de-serialize thrift-encoded data without > needing to create a cassandra/server connection. Exporting access to the > inner transport and protocol classes will enable that. -- 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] [Resolved] (THRIFT-336) Compact Protocol in C#
[ https://issues.apache.org/jira/browse/THRIFT-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henrique Mendonca resolved THRIFT-336. -- Resolution: Implemented Fix Version/s: 0.9 Committed without the commented out lines. > Compact Protocol in C# > -- > > Key: THRIFT-336 > URL: https://issues.apache.org/jira/browse/THRIFT-336 > Project: Thrift > Issue Type: Sub-task > Components: C# - Library >Reporter: Michael Greene >Assignee: Henrique Mendonca >Priority: Minor > Fix For: 0.9 > > Attachments: TCompactProtocol.cs, THRIFT-336.patch > > -- 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] [Closed] (THRIFT-1703) Add leading :: to cpp names
[ https://issues.apache.org/jira/browse/THRIFT-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henrique Mendonca closed THRIFT-1703. - > Add leading :: to cpp names > --- > > Key: THRIFT-1703 > URL: https://issues.apache.org/jira/browse/THRIFT-1703 > Project: Thrift > Issue Type: Bug > Components: C++ - Compiler >Affects Versions: 0.8, 0.9 >Reporter: Jochen Topf >Assignee: Henrique Mendonca > Attachments: thrift-1703.patch > > > In some places the C++ code generated doesn't have leading :: on namespaced > names causing it to fail when used. > Supplied patch is against svn trunk. 0.8 has a similar problem. -- 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] [Resolved] (THRIFT-1703) Add leading :: to cpp names
[ https://issues.apache.org/jira/browse/THRIFT-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henrique Mendonca resolved THRIFT-1703. --- Resolution: Fixed > Add leading :: to cpp names > --- > > Key: THRIFT-1703 > URL: https://issues.apache.org/jira/browse/THRIFT-1703 > Project: Thrift > Issue Type: Bug > Components: C++ - Compiler >Affects Versions: 0.8, 0.9 >Reporter: Jochen Topf >Assignee: Henrique Mendonca > Attachments: thrift-1703.patch > > > In some places the C++ code generated doesn't have leading :: on namespaced > names causing it to fail when used. > Supplied patch is against svn trunk. 0.8 has a similar problem. -- 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] [Assigned] (THRIFT-1703) Add leading :: to cpp names
[ https://issues.apache.org/jira/browse/THRIFT-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henrique Mendonca reassigned THRIFT-1703: - Assignee: Henrique Mendonca > Add leading :: to cpp names > --- > > Key: THRIFT-1703 > URL: https://issues.apache.org/jira/browse/THRIFT-1703 > Project: Thrift > Issue Type: Bug > Components: C++ - Compiler >Affects Versions: 0.8, 0.9 >Reporter: Jochen Topf >Assignee: Henrique Mendonca > Attachments: thrift-1703.patch > > > In some places the C++ code generated doesn't have leading :: on namespaced > names causing it to fail when used. > Supplied patch is against svn trunk. 0.8 has a similar problem. -- 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] [Closed] (THRIFT-1701) node.js TBufferedTransport buffer corruption
[ https://issues.apache.org/jira/browse/THRIFT-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henrique Mendonca closed THRIFT-1701. - Resolution: Fixed > node.js TBufferedTransport buffer corruption > > > Key: THRIFT-1701 > URL: https://issues.apache.org/jira/browse/THRIFT-1701 > Project: Thrift > Issue Type: Bug > Components: Node.js - Library >Reporter: Marshall Roch > Attachments: thrift-1701-node-buffer-corruption.patch > > > Node's Buffer.copy's 3rd and 4th arguments are the start and end indexes to > copy. There are two callers in the nodejs implementation of > TBufferedTransport that pass a length instead of an end index as the 4th > argument. > http://nodejs.org/api/buffer.html#buffer_buf_copy_targetbuffer_targetstart_sourcestart_sourceend -- 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] (THRIFT-1701) node.js TBufferedTransport buffer corruption
[ https://issues.apache.org/jira/browse/THRIFT-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13462015#comment-13462015 ] Henrique Mendonca commented on THRIFT-1701: --- I think you have a good point and I'm committing it but it unfortunately doesn't fix the TBufferedTransport. e.g. thrift/test/nodejs$ timeout 2 make server & sleep 1; make client only runs one or two tests before stopping/crashing when using TBufferedTransport. > node.js TBufferedTransport buffer corruption > > > Key: THRIFT-1701 > URL: https://issues.apache.org/jira/browse/THRIFT-1701 > Project: Thrift > Issue Type: Bug > Components: Node.js - Library >Reporter: Marshall Roch > Attachments: thrift-1701-node-buffer-corruption.patch > > > Node's Buffer.copy's 3rd and 4th arguments are the start and end indexes to > copy. There are two callers in the nodejs implementation of > TBufferedTransport that pass a length instead of an end index as the 4th > argument. > http://nodejs.org/api/buffer.html#buffer_buf_copy_targetbuffer_targetstart_sourcestart_sourceend -- 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] [Closed] (THRIFT-1696) Compiler fails if namespace of an unknown language is present in the IDL
[ https://issues.apache.org/jira/browse/THRIFT-1696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henrique Mendonca closed THRIFT-1696. - committed > Compiler fails if namespace of an unknown language is present in the IDL > > > Key: THRIFT-1696 > URL: https://issues.apache.org/jira/browse/THRIFT-1696 > Project: Thrift > Issue Type: Bug > Components: Compiler (General) >Reporter: Abhishek Kona >Priority: Minor > Labels: compiler > Attachments: thrift-0.9.0-ignore-bad-namespace-language.patch > > > Name space declaration for an unknown language, should not fail the compiler. > The code-gen should continue ignoring the unknown namespace. -- 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] [Resolved] (THRIFT-1696) Compiler fails if namespace of an unknown language is present in the IDL
[ https://issues.apache.org/jira/browse/THRIFT-1696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henrique Mendonca resolved THRIFT-1696. --- Resolution: Fixed Assignee: (was: Henrique Mendonca) > Compiler fails if namespace of an unknown language is present in the IDL > > > Key: THRIFT-1696 > URL: https://issues.apache.org/jira/browse/THRIFT-1696 > Project: Thrift > Issue Type: Bug > Components: Compiler (General) >Reporter: Abhishek Kona >Priority: Minor > Labels: compiler > Attachments: thrift-0.9.0-ignore-bad-namespace-language.patch > > > Name space declaration for an unknown language, should not fail the compiler. > The code-gen should continue ignoring the unknown namespace. -- 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] [Assigned] (THRIFT-1696) Compiler fails if namespace of an unknown language is present in the IDL
[ https://issues.apache.org/jira/browse/THRIFT-1696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henrique Mendonca reassigned THRIFT-1696: - Assignee: Henrique Mendonca > Compiler fails if namespace of an unknown language is present in the IDL > > > Key: THRIFT-1696 > URL: https://issues.apache.org/jira/browse/THRIFT-1696 > Project: Thrift > Issue Type: Bug > Components: Compiler (General) >Reporter: Abhishek Kona >Assignee: Henrique Mendonca >Priority: Minor > Labels: compiler > Attachments: thrift-0.9.0-ignore-bad-namespace-language.patch > > > Name space declaration for an unknown language, should not fail the compiler. > The code-gen should continue ignoring the unknown namespace. -- 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] (THRIFT-336) Compact Protocol in C#
[ https://issues.apache.org/jira/browse/THRIFT-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henrique Mendonca updated THRIFT-336: - Attachment: TCompactProtocol.cs THRIFT-336.patch I'd commit this if nobody has anything against it. I've converted it from the java version and although I've tested quite a lot against the c++ version I think I'll try to change its test script to also accept the new protocol. Another two things: 1. I've left all references to trans.getBytesRemainingInBuffer() commented out, I'm not sure if this is a java thing only but the normal binary protocol does not have anything similar. 2. I run into problems encoding integers larger than 0x4000 due to issues involving shift on signed integers. I am pretty sure the VarInt and ZigZag type have to be handled as an unsigned. This is the only change on the code from the original Java implementation and I think it could be that this problem would also happen there. I'd be glad if someone could have a look on that (and/or on the Java version). Thank you > Compact Protocol in C# > -- > > Key: THRIFT-336 > URL: https://issues.apache.org/jira/browse/THRIFT-336 > Project: Thrift > Issue Type: Sub-task > Components: C# - Library >Reporter: Michael Greene >Assignee: Henrique Mendonca >Priority: Minor > Attachments: TCompactProtocol.cs, THRIFT-336.patch > > -- 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] (THRIFT-1700) Number overflow in ReadFrame.
[
https://issues.apache.org/jira/browse/THRIFT-1700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13460614#comment-13460614
]
Henrique Mendonca commented on THRIFT-1700:
---
Sometimes? where? it would be nice if we could reproduce it, e.g. unit-tests
then please read http://thrift.apache.org/docs/HowToContribute/
is this the TBinaryProtocol?
does it get resolved if you change it to *uint size = ...* ?
> Number overflow in ReadFrame.
> -
>
> Key: THRIFT-1700
> URL: https://issues.apache.org/jira/browse/THRIFT-1700
> Project: Thrift
> Issue Type: Bug
> Components: C# - Library
>Affects Versions: 0.8
>Reporter: Alexey
>
> private void ReadFrame()
> {
> byte[] i32rd = new byte[header_size];
> transport.ReadAll(i32rd, 0, header_size);
> int size =
> ((i32rd[0] & 0xff) << 24) |
> ((i32rd[1] & 0xff) << 16) |
> ((i32rd[2] & 0xff) << 8) |
> ((i32rd[3] & 0xff));
> byte[] buff = new byte[size];
> transport.ReadAll(buff, 0, size);
> readBuffer = new MemoryStream(buff);
> }
> Here, when calculating size, number overflow throws sometimes.
--
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] [Assigned] (THRIFT-336) Compact Protocol in C#
[ https://issues.apache.org/jira/browse/THRIFT-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henrique Mendonca reassigned THRIFT-336: Assignee: Henrique Mendonca > Compact Protocol in C# > -- > > Key: THRIFT-336 > URL: https://issues.apache.org/jira/browse/THRIFT-336 > Project: Thrift > Issue Type: Sub-task > Components: C# - Library >Reporter: Michael Greene >Assignee: Henrique Mendonca >Priority: Minor > -- 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] [Closed] (THRIFT-1689) don't exit(-1) in TNonblockingServer
[ https://issues.apache.org/jira/browse/THRIFT-1689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henrique Mendonca closed THRIFT-1689. - > don't exit(-1) in TNonblockingServer > > > Key: THRIFT-1689 > URL: https://issues.apache.org/jira/browse/THRIFT-1689 > Project: Thrift > Issue Type: Bug > Components: C++ - Library >Affects Versions: 0.8 >Reporter: Brian Fallik >Assignee: Brian Fallik >Priority: Minor > Fix For: 0.9 > > Attachments: 1689.patch > > > TNonblockingServer calls exit(-1) when it encounters a std::bad_alloc > exception. The -1 argument to exit() is problematic. Programs typically use > non-zero exit codes since negative values are reserved for signals. On > somewhat modern Linux (CentOS 6.0), exit(-1) causes the process to yield > return code 255. which BASH claims is out of range: > http://tldp.org/LDP/abs/html/exitcodes.html > I don't see any advantage to exit(-1) in this case. If the intent is to exit > with an error indication, 1 (or the EXIT_FAILURE macro) should do fine. If > the intent is to signal program termination, possibly with a stack trace, > abrt() would be better. > Attached is a patch for the simplest change from '-1' to '1'. > Thanks. -- 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] [Resolved] (THRIFT-1689) don't exit(-1) in TNonblockingServer
[ https://issues.apache.org/jira/browse/THRIFT-1689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henrique Mendonca resolved THRIFT-1689. --- Resolution: Fixed > don't exit(-1) in TNonblockingServer > > > Key: THRIFT-1689 > URL: https://issues.apache.org/jira/browse/THRIFT-1689 > Project: Thrift > Issue Type: Bug > Components: C++ - Library >Affects Versions: 0.8 >Reporter: Brian Fallik >Assignee: Brian Fallik >Priority: Minor > Fix For: 0.9 > > Attachments: 1689.patch > > > TNonblockingServer calls exit(-1) when it encounters a std::bad_alloc > exception. The -1 argument to exit() is problematic. Programs typically use > non-zero exit codes since negative values are reserved for signals. On > somewhat modern Linux (CentOS 6.0), exit(-1) causes the process to yield > return code 255. which BASH claims is out of range: > http://tldp.org/LDP/abs/html/exitcodes.html > I don't see any advantage to exit(-1) in this case. If the intent is to exit > with an error indication, 1 (or the EXIT_FAILURE macro) should do fine. If > the intent is to signal program termination, possibly with a stack trace, > abrt() would be better. > Attached is a patch for the simplest change from '-1' to '1'. > Thanks. -- 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] (THRIFT-1689) don't exit(-1) in TNonblockingServer
[ https://issues.apache.org/jira/browse/THRIFT-1689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13452385#comment-13452385 ] Henrique Mendonca commented on THRIFT-1689: --- Hi Brian, Thanks for the patch. I was just wondering, which version of bash are you using? I think EXIT_FAILURE is anyway a good idea unless you need to include cstdlib just for this sake. Anyone against it? If not, I'd be happy to commit it. > don't exit(-1) in TNonblockingServer > > > Key: THRIFT-1689 > URL: https://issues.apache.org/jira/browse/THRIFT-1689 > Project: Thrift > Issue Type: Bug > Components: C++ - Library >Affects Versions: 0.8 >Reporter: Brian Fallik >Priority: Minor > Fix For: 0.9 > > Attachments: 1689.patch > > > TNonblockingServer calls exit(-1) when it encounters a std::bad_alloc > exception. The -1 argument to exit() is problematic. Programs typically use > non-zero exit codes since negative values are reserved for signals. On > somewhat modern Linux (CentOS 6.0), exit(-1) causes the process to yield > return code 255. which BASH claims is out of range: > http://tldp.org/LDP/abs/html/exitcodes.html > I don't see any advantage to exit(-1) in this case. If the intent is to exit > with an error indication, 1 (or the EXIT_FAILURE macro) should do fine. If > the intent is to signal program termination, possibly with a stack trace, > abrt() would be better. > Attached is a patch for the simplest change from '-1' to '1'. > Thanks. -- 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] (THRIFT-1640) None of the tutorials linked on the website contain content
[ https://issues.apache.org/jira/browse/THRIFT-1640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13443813#comment-13443813 ] Henrique Mendonca commented on THRIFT-1640: --- Good job Richard, thanks heaps! I'll try to add some doc and tutorial for the JS asynchronous calls as well, probably as another ticket after this gets to the trunk. > None of the tutorials linked on the website contain content > --- > > Key: THRIFT-1640 > URL: https://issues.apache.org/jira/browse/THRIFT-1640 > Project: Thrift > Issue Type: Bug > Components: Website > Environment: The internet! >Reporter: Alex Gaynor >Assignee: Jake Farrell > Attachments: thrift-1640-js.md.patch > > > Steps to reproduce: > 1) Visit http://thrift.apache.org/tutorial/ > 2) Click on any of the languages listed in "Examples Clients and Servers" > 3) Wonder where the content is? > Expected result: > To be reading an example client and/or server and learning! -- 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] (THRIFT-1683) Implement alternatives to Javascript Client side Transport protocol, just as NPAPI and WebSocket.
[ https://issues.apache.org/jira/browse/THRIFT-1683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13443510#comment-13443510 ] Henrique Mendonca commented on THRIFT-1683: --- Thanks Richard, as already discussed per mail, I was thinking to implement this using socket.io which would probably facilitate the cross-language implementation for the server side and offer some extra features for the client: [https://github.com/learnboost/socket.io/wiki/] but yeah it's totally your call. I won't have much time but I can try to give you a hand if you need, so keep in touch! ps.: as for NPAPI we could add a separated ticket for that, what do you think? > Implement alternatives to Javascript Client side Transport protocol, just as > NPAPI and WebSocket. > - > > Key: THRIFT-1683 > URL: https://issues.apache.org/jira/browse/THRIFT-1683 > Project: Thrift > Issue Type: Improvement > Components: JavaScript - Library >Affects Versions: 0.8, 0.9, 1.0, 1.1 > Environment: Client side development >Reporter: Richard Elswick > Labels: WebSocket, client, javascript, performance > Original Estimate: 336h > Remaining Estimate: 336h > > The current Thrift.js Transport mechanism is only via AJAX. This should > support the ability to choose the type as AJAX or WebSocket. An additional > mechanism, which may make sense is a native call as well, through NPAPI or > JSExtensions. This makes it useful for Embedded devices, which implement > these methods. -- 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] (THRIFT-1640) None of the tutorials linked on the website contain content
[ https://issues.apache.org/jira/browse/THRIFT-1640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13443358#comment-13443358 ] Henrique Mendonca commented on THRIFT-1640: --- +1 what about [http://wiki.apache.org/thrift/ThriftUsage], link or copy? However most of the pages are not very useful. Is it just outdated or it has another function that I can't seem to understand? Cheers > None of the tutorials linked on the website contain content > --- > > Key: THRIFT-1640 > URL: https://issues.apache.org/jira/browse/THRIFT-1640 > Project: Thrift > Issue Type: Bug > Components: Website > Environment: The internet! >Reporter: Alex Gaynor >Assignee: Jake Farrell > > Steps to reproduce: > 1) Visit http://thrift.apache.org/tutorial/ > 2) Click on any of the languages listed in "Examples Clients and Servers" > 3) Wonder where the content is? > Expected result: > To be reading an example client and/or server and learning! -- 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] (THRIFT-1647) NodeJS FramedTransport does not work beyond the hello-world example
[ https://issues.apache.org/jira/browse/THRIFT-1647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13426865#comment-13426865 ] Henrique Mendonca commented on THRIFT-1647: --- Sorry, but do you mean BufferedTransport doesn't work and FramedTransport does? Could you please fix the title and description? Cheers I'm not very familiar with the transport implementation, tough > NodeJS FramedTransport does not work beyond the hello-world example > --- > > Key: THRIFT-1647 > URL: https://issues.apache.org/jira/browse/THRIFT-1647 > Project: Thrift > Issue Type: Bug > Components: Node.js - Library >Affects Versions: 0.8 > Environment: Ubuntu 12.04, NodeJS v0.6;v0.8.0 >Reporter: Dan Cromer >Priority: Minor > > During the setup of NodeJS <-> Apache Thrift integration, we found that the > use of BufferedTransport did not work beyond the HelloWorld example. While > NodeJS clients were able to connect, no service invocations actually > registered with the server (Java, Thrift 0.8.0) > Switching to the use of a BufferedTransport immediately fixed the issue. I > was unable to debug the issue, but wanted to file an issue so that others > were aware. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (THRIFT-1659) Bring nodejs default transport in line with Java default transport
[ https://issues.apache.org/jira/browse/THRIFT-1659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13423000#comment-13423000 ] Henrique Mendonca commented on THRIFT-1659: --- +1, but it breaks the current tests: make -C test/nodejs server & make -C test/nodejs client sorry i didn't have much time to find out the reason Cheers, Henrique > Bring nodejs default transport in line with Java default transport > -- > > Key: THRIFT-1659 > URL: https://issues.apache.org/jira/browse/THRIFT-1659 > Project: Thrift > Issue Type: Improvement > Components: Node.js - Library >Affects Versions: 0.8, 0.9 >Reporter: Eldon Stegall > Attachments: thrift-change-nodejs-default-transport.patch > > > By default, when java servers are created, they use the equivalent of the > TBufferedTransport, which is the vanilla transport in java, but node.js > clients use the TFramedTransport by default. In the interest of making > compatibility between libraries the goal, the node.js library should use the > TBufferedTransport by default. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (THRIFT-1353) Switch to performance branch, get rid of BinaryParser
[ https://issues.apache.org/jira/browse/THRIFT-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13411300#comment-13411300 ] Henrique Mendonca commented on THRIFT-1353: --- Not really, just wanted to facilitate it for the committers and testers. Talked briefly to Roger before but I wasn't sure whether Jenkins would handle the NPM. We can definitely leave the files from node-int64 uncommitted if it works. Thanks for having a look anyways! > Switch to performance branch, get rid of BinaryParser > - > > Key: THRIFT-1353 > URL: https://issues.apache.org/jira/browse/THRIFT-1353 > Project: Thrift > Issue Type: Improvement > Components: Node.js - Library >Affects Versions: 0.7 >Reporter: Hans Duedal >Assignee: Roger Meier > Labels: node, nodejs > Fix For: 1.0 > > Attachments: THRIFT-1353-noBinaryParser-BufferedTrans-Int64-v3.patch > > > I vote that the thrift library switches to the performance branch at > https://github.com/wadey/node-thrift/tree/performance > I much prefer using the node.js buffers over the BinaryParser class, the > performance branch seems focused on this very issue. Also it includes the > excellent int64 implementation from broofa. What's not to like? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (THRIFT-1353) Switch to performance branch, get rid of BinaryParser
[ https://issues.apache.org/jira/browse/THRIFT-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13399278#comment-13399278 ] Henrique Mendonca edited comment on THRIFT-1353 at 6/22/12 12:04 PM: - Here it is, finally. THRIFT-1353-noBinaryParser-BufferedTrans-Int64-v3.patch cleaned up and rebased for today's trunk It also includes the files from node-int64 ps: the test from cpp client to nodejs server still fails but we're getting there... ps2: rewriting the nodejs test client to use the assert module would be also nice... ps3: patch with -p0 please was (Author: henrique): Here it is, finally. THRIFT-1353-noBinaryParser-BufferedTrans-Int64-v3.patch cleaned up and rebased for today's trunk It also includes the files from node-int64 ps: the test from cpp client to nodejs server still fails but we're getting there... ps2: rewriting the nodejs test client to use the assert module would be also nice... > Switch to performance branch, get rid of BinaryParser > - > > Key: THRIFT-1353 > URL: https://issues.apache.org/jira/browse/THRIFT-1353 > Project: Thrift > Issue Type: Improvement > Components: Node.js - Library >Affects Versions: 0.7 >Reporter: Hans Duedal >Assignee: Roger Meier > Labels: node, nodejs > Fix For: 1.0 > > Attachments: THRIFT-1353-noBinaryParser-BufferedTrans-Int64-v3.patch > > > I vote that the thrift library switches to the performance branch at > https://github.com/wadey/node-thrift/tree/performance > I much prefer using the node.js buffers over the BinaryParser class, the > performance branch seems focused on this very issue. Also it includes the > excellent int64 implementation from broofa. What's not to like? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (THRIFT-1353) Switch to performance branch, get rid of BinaryParser
[ https://issues.apache.org/jira/browse/THRIFT-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henrique Mendonca updated THRIFT-1353: -- Attachment: THRIFT-1353-noBinaryParser-BufferedTrans-Int64-v3.patch Here it is, finally. THRIFT-1353-noBinaryParser-BufferedTrans-Int64-v3.patch cleaned up and rebased for today's trunk It also includes the files from node-int64 ps: the test from cpp client to nodejs server still fails but we're getting there... ps2: rewriting the nodejs test client to use the assert module would be also nice... > Switch to performance branch, get rid of BinaryParser > - > > Key: THRIFT-1353 > URL: https://issues.apache.org/jira/browse/THRIFT-1353 > Project: Thrift > Issue Type: Improvement > Components: Node.js - Library >Affects Versions: 0.7 >Reporter: Hans Duedal >Assignee: Roger Meier > Labels: node, nodejs > Fix For: 1.0 > > Attachments: THRIFT-1353-noBinaryParser-BufferedTrans-Int64-v3.patch > > > I vote that the thrift library switches to the performance branch at > https://github.com/wadey/node-thrift/tree/performance > I much prefer using the node.js buffers over the BinaryParser class, the > performance branch seems focused on this very issue. Also it includes the > excellent int64 implementation from broofa. What's not to like? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (THRIFT-1353) Switch to performance branch, get rid of BinaryParser
[ https://issues.apache.org/jira/browse/THRIFT-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henrique Mendonca updated THRIFT-1353: -- Attachment: (was: THRIFT-1353-noBinaryParser-BufferedTrans-Int64.patch) > Switch to performance branch, get rid of BinaryParser > - > > Key: THRIFT-1353 > URL: https://issues.apache.org/jira/browse/THRIFT-1353 > Project: Thrift > Issue Type: Improvement > Components: Node.js - Library >Affects Versions: 0.7 >Reporter: Hans Duedal >Assignee: Roger Meier > Labels: node, nodejs > Fix For: 1.0 > > Attachments: THRIFT-1353-noBinaryParser-BufferedTrans-Int64-v3.patch > > > I vote that the thrift library switches to the performance branch at > https://github.com/wadey/node-thrift/tree/performance > I much prefer using the node.js buffers over the BinaryParser class, the > performance branch seems focused on this very issue. Also it includes the > excellent int64 implementation from broofa. What's not to like? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (THRIFT-1353) Switch to performance branch, get rid of BinaryParser
[ https://issues.apache.org/jira/browse/THRIFT-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13274755#comment-13274755 ] Henrique Mendonca commented on THRIFT-1353: --- Thanks for you feedback Wade. I think we should check this in as it fix some bugs and improve other stuff. Got your code to run but didn't manage to create a proper patch (too many files and other conflicts). I also don't work directly with it, only had some ideas which would require it, so it's also hard for me to dedicate time for it. However, I should get this running within the next weeks. Thanks for your contribution anyway! Henrique > Switch to performance branch, get rid of BinaryParser > - > > Key: THRIFT-1353 > URL: https://issues.apache.org/jira/browse/THRIFT-1353 > Project: Thrift > Issue Type: Improvement > Components: Node.js - Library >Affects Versions: 0.7 >Reporter: Hans Duedal >Assignee: Roger Meier > Labels: node, nodejs > Fix For: 0.9 > > Attachments: THRIFT-1353-noBinaryParser-BufferedTrans-Int64.patch > > > I vote that the thrift library switches to the performance branch at > https://github.com/wadey/node-thrift/tree/performance > I much prefer using the node.js buffers over the BinaryParser class, the > performance branch seems focused on this very issue. Also it includes the > excellent int64 implementation from broofa. What's not to like? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (THRIFT-579) Alternative ASIO based fully async client/server for C++
[ https://issues.apache.org/jira/browse/THRIFT-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13270702#comment-13270702 ] Henrique Mendonca commented on THRIFT-579: -- +1 that! > Alternative ASIO based fully async client/server for C++ > > > Key: THRIFT-579 > URL: https://issues.apache.org/jira/browse/THRIFT-579 > Project: Thrift > Issue Type: Sub-task > Components: C++ - Compiler, C++ - Library >Reporter: Bruce Simpson > Attachments: CppClient.cpp, CppServer.cpp, TAsioAsync.cpp, > TAsioAsync.h, TAsync.h, TFuture.h, THRIFT-579_against_trunk_1243124.patch, > THRIFT-579_v2_against_trunk_1304085.patch, erikb-asio.patch, > thrift-async-817938.diff > > > I'm raising this JIRA on behalf of Erik Bernhardsson. > Seems this was submitted to the JIRA list on Wed 9 Sep 2009, but I didn't see > it until I skimmed the JIRA list feed for thrift-dev. > I'll attach his original files shortly, though I may just fold them into an > SVN trunk checkout first and post the diff. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (THRIFT-1514) Callbacks with newer jQuery versions don't work
[
https://issues.apache.org/jira/browse/THRIFT-1514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13269579#comment-13269579
]
Henrique Mendonca commented on THRIFT-1514:
---
hm... this is not back compatible with the legacy code (i.e.
error(function(xhr,status,e)..., sucess(result, [call_arguments])), which is
kind of a shame... However, it's a good simplification of the code.
Does it bother anyone else?
> Callbacks with newer jQuery versions don't work
> ---
>
> Key: THRIFT-1514
> URL: https://issues.apache.org/jira/browse/THRIFT-1514
> Project: Thrift
> Issue Type: Bug
> Components: JavaScript - Library
>Affects Versions: 0.9
>Reporter: Kenny
>Assignee: Andrew Grumet
>Priority: Minor
> Attachments: THRIFT-1514.patch
>
>
> When using jQuery 1.7.1 callbacks don't work. The following error is returned:
> TypeError: Object function ( selector, context ) { // The jQuery object is
> actually just the init constructor 'enhanced' return new jQuery.fn.init(
> selector, context, rootjQuery ); } has no method '_Deferred'
> It seems _Deferred no longer exists.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (THRIFT-1238) Thrift JS client cannot read map of structures
[
https://issues.apache.org/jira/browse/THRIFT-1238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henrique Mendonca resolved THRIFT-1238.
---
Resolution: Fixed
> Thrift JS client cannot read map of structures
> --
>
> Key: THRIFT-1238
> URL: https://issues.apache.org/jira/browse/THRIFT-1238
> Project: Thrift
> Issue Type: Bug
> Components: JavaScript - Compiler, JavaScript - Library
>Affects Versions: 0.6.1
>Reporter: Henrique Mendonca
> Labels: javascript
> Fix For: 0.8
>
> Attachments: THRIFT-1238-fix-maps+qunit.patch,
> THRIFT-1238-qunit-insanity.patch
>
>
> Apparently we have a problem reading map of structures, only one item is been
> read and the other come as undefined in the result map on the client side.
> I was having this with some complex maps and notice that the test case
> 'testInsanity' was quite similar to my case but was actually been tested at
> all. Then checking its result I could see that's it actually a general
> problem.
> The server sends 2 elements:
> {code}
> {
> "1":{
> "3":{
> "userMap":{
> "8":8,
> "5":5
> },
> "xtructs":[{
> "string_thing":"Goodbye4",
> "byte_thing":4,
> "i32_thing":4,
> "i64_thing":4
> },
> {
> "string_thing":"Hello2",
> "byte_thing":2,
> "i32_thing":2,
> "i64_thing":2
> }
> ]
> },
> "2":{
> "userMap":{
> "8":8,
> "5":5
> },
> "xtructs":[{
> "string_thing":"Goodbye4",
> "byte_thing":4,
> "i32_thing":4,
> "i64_thing":4
> },
> {
> "string_thing":"Hello2",
> "byte_thing":2,
> "i32_thing":2,
> "i64_thing":2
> }
> ]
> }
> },
> "2":{
> "6":{
> "userMap":null,
> "xtructs":null
> }
> }
> }
> {code}
> but we can only read 1:
> {code}
> {
> "1":{
> "2":{
> "userMap":{
> "8":8,
> "5":5
> },
> "xtructs":[{
> "string_thing":"Goodbye4",
> "byte_thing":4,
> "i32_thing":4,
> "i64_thing":4
> },
> {
> "string_thing":"Hello2",
> "byte_thing":2,
> "i32_thing":2,
> "i64_thing":2
> }
> ]
> },
> "undefined":{
> "userMap":null,
> "xtructs":null
> }
> },
> "2":{
> "6":{
> "userMap":null,
> "xtructs":null
> }
> }
> }
> {code}
> on my code it also happens with 3 or more structures, only the first one is
> read, the second is "undefined" and the rest is gone!
> ps.: I'm submitting the patch for the unit test. I had a quick look on the
> code but could find anything yet and won't have time in the next weeks...
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (THRIFT-1238) Thrift JS client cannot read map of structures
[
https://issues.apache.org/jira/browse/THRIFT-1238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henrique Mendonca updated THRIFT-1238:
--
Attachment: THRIFT-1238-fix-maps+qunit.patch
finally: THRIFT-1238-fix-maps+qunit.patch
Although I still see a weird behavior with lis>, it should fix
most of the problems with maps deserialization.
> Thrift JS client cannot read map of structures
> --
>
> Key: THRIFT-1238
> URL: https://issues.apache.org/jira/browse/THRIFT-1238
> Project: Thrift
> Issue Type: Bug
> Components: JavaScript - Compiler, JavaScript - Library
>Affects Versions: 0.6.1
>Reporter: Henrique Mendonca
> Labels: javascript
> Fix For: 0.8
>
> Attachments: THRIFT-1238-fix-maps+qunit.patch,
> THRIFT-1238-qunit-insanity.patch
>
>
> Apparently we have a problem reading map of structures, only one item is been
> read and the other come as undefined in the result map on the client side.
> I was having this with some complex maps and notice that the test case
> 'testInsanity' was quite similar to my case but was actually been tested at
> all. Then checking its result I could see that's it actually a general
> problem.
> The server sends 2 elements:
> {code}
> {
> "1":{
> "3":{
> "userMap":{
> "8":8,
> "5":5
> },
> "xtructs":[{
> "string_thing":"Goodbye4",
> "byte_thing":4,
> "i32_thing":4,
> "i64_thing":4
> },
> {
> "string_thing":"Hello2",
> "byte_thing":2,
> "i32_thing":2,
> "i64_thing":2
> }
> ]
> },
> "2":{
> "userMap":{
> "8":8,
> "5":5
> },
> "xtructs":[{
> "string_thing":"Goodbye4",
> "byte_thing":4,
> "i32_thing":4,
> "i64_thing":4
> },
> {
> "string_thing":"Hello2",
> "byte_thing":2,
> "i32_thing":2,
> "i64_thing":2
> }
> ]
> }
> },
> "2":{
> "6":{
> "userMap":null,
> "xtructs":null
> }
> }
> }
> {code}
> but we can only read 1:
> {code}
> {
> "1":{
> "2":{
> "userMap":{
> "8":8,
> "5":5
> },
> "xtructs":[{
> "string_thing":"Goodbye4",
> "byte_thing":4,
> "i32_thing":4,
> "i64_thing":4
> },
> {
> "string_thing":"Hello2",
> "byte_thing":2,
> "i32_thing":2,
> "i64_thing":2
> }
> ]
> },
> "undefined":{
> "userMap":null,
> "xtructs":null
> }
> },
> "2":{
> "6":{
> "userMap":null,
> "xtructs":null
> }
> }
> }
> {code}
> on my code it also happens with 3 or more structures, only the first one is
> read, the second is "undefined" and the rest is gone!
> ps.: I'm submitting the patch for the unit test. I had a quick look on the
> code but could find anything yet and won't have time in the next weeks...
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (THRIFT-1311) Recent changes on Java library break Java JSON protocol
[
https://issues.apache.org/jira/browse/THRIFT-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henrique Mendonca closed THRIFT-1311.
-
Resolution: Fixed
> Recent changes on Java library break Java JSON protocol
> ---
>
> Key: THRIFT-1311
> URL: https://issues.apache.org/jira/browse/THRIFT-1311
> Project: Thrift
> Issue Type: Bug
> Components: Java - Library
>Reporter: Henrique Mendonca
> Labels: java, javascript, qunit
>
> I see that some people have been working very hard on the Java library and
> that's really appreciated, however, some of the changes seem to have
> interfered with the java server JSON/HTTP implementation which is used to
> test the JS client. Please see below:
> thrift/lib/js/test$ ant testserver
> [...]
> [java] New connection thread
> [java] Incoming content: [1,"testSet",1,0,{"1":{"set":["i32",3,1,2,3]}}]
> [java] Outgoing content: Error:Unexpected character:[
> [java] New connection thread
> [java] Incoming content: [1,"testList",1,0,{"1":{"lst":["i32",3,1,2,3]}}]
> [java] Outgoing content: Error:Unexpected character:[
> ps.: I hope one day we can automatize these tests with node.js, or something
> like that, so we don't need to run this manually
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (THRIFT-1311) Recent changes on Java library break Java JSON protocol
[
https://issues.apache.org/jira/browse/THRIFT-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13095874#comment-13095874
]
Henrique Mendonca commented on THRIFT-1311:
---
Awesome, it works again
Thanks heaps Bryan
> Recent changes on Java library break Java JSON protocol
> ---
>
> Key: THRIFT-1311
> URL: https://issues.apache.org/jira/browse/THRIFT-1311
> Project: Thrift
> Issue Type: Bug
> Components: Java - Library
>Reporter: Henrique Mendonca
> Labels: java, javascript, qunit
>
> I see that some people have been working very hard on the Java library and
> that's really appreciated, however, some of the changes seem to have
> interfered with the java server JSON/HTTP implementation which is used to
> test the JS client. Please see below:
> thrift/lib/js/test$ ant testserver
> [...]
> [java] New connection thread
> [java] Incoming content: [1,"testSet",1,0,{"1":{"set":["i32",3,1,2,3]}}]
> [java] Outgoing content: Error:Unexpected character:[
> [java] New connection thread
> [java] Incoming content: [1,"testList",1,0,{"1":{"lst":["i32",3,1,2,3]}}]
> [java] Outgoing content: Error:Unexpected character:[
> ps.: I hope one day we can automatize these tests with node.js, or something
> like that, so we don't need to run this manually
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (THRIFT-1311) Recent changes on Java library break Java JSON protocol
Recent changes on Java library break Java JSON protocol
---
Key: THRIFT-1311
URL: https://issues.apache.org/jira/browse/THRIFT-1311
Project: Thrift
Issue Type: Bug
Components: Java - Library
Reporter: Henrique Mendonca
I see that some people have been working very hard on the Java library and
that's really appreciated, however, some of the changes seem to have interfered
with the java server JSON/HTTP implementation which is used to test the JS
client. Please see below:
thrift/lib/js/test$ ant testserver
[...]
[java] New connection thread
[java] Incoming content: [1,"testSet",1,0,{"1":{"set":["i32",3,1,2,3]}}]
[java] Outgoing content: Error:Unexpected character:[
[java] New connection thread
[java] Incoming content: [1,"testList",1,0,{"1":{"lst":["i32",3,1,2,3]}}]
[java] Outgoing content: Error:Unexpected character:[
ps.: I hope one day we can automatize these tests with node.js, or something
like that, so we don't need to run this manually
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (THRIFT-1238) Thrift JS client cannot read map of structures
[
https://issues.apache.org/jira/browse/THRIFT-1238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henrique Mendonca updated THRIFT-1238:
--
Attachment: THRIFT-1238-qunit-insanity.patch
> Thrift JS client cannot read map of structures
> --
>
> Key: THRIFT-1238
> URL: https://issues.apache.org/jira/browse/THRIFT-1238
> Project: Thrift
> Issue Type: Bug
> Components: JavaScript - Compiler, JavaScript - Library
>Affects Versions: 0.6.1
>Reporter: Henrique Mendonca
> Labels: javascript
> Attachments: THRIFT-1238-qunit-insanity.patch
>
>
> Apparently we have a problem reading map of structures, only one item is been
> read and the other come as undefined in the result map on the client side.
> I was having this with some complex maps and notice that the test case
> 'testInsanity' was quite similar to my case but was actually been tested at
> all. Then checking its result I could see that's it actually a general
> problem.
> The server sends 2 elements:
> {code}
> {
> "1":{
> "3":{
> "userMap":{
> "8":8,
> "5":5
> },
> "xtructs":[{
> "string_thing":"Goodbye4",
> "byte_thing":4,
> "i32_thing":4,
> "i64_thing":4
> },
> {
> "string_thing":"Hello2",
> "byte_thing":2,
> "i32_thing":2,
> "i64_thing":2
> }
> ]
> },
> "2":{
> "userMap":{
> "8":8,
> "5":5
> },
> "xtructs":[{
> "string_thing":"Goodbye4",
> "byte_thing":4,
> "i32_thing":4,
> "i64_thing":4
> },
> {
> "string_thing":"Hello2",
> "byte_thing":2,
> "i32_thing":2,
> "i64_thing":2
> }
> ]
> }
> },
> "2":{
> "6":{
> "userMap":null,
> "xtructs":null
> }
> }
> }
> {code}
> but we can only read 1:
> {code}
> {
> "1":{
> "2":{
> "userMap":{
> "8":8,
> "5":5
> },
> "xtructs":[{
> "string_thing":"Goodbye4",
> "byte_thing":4,
> "i32_thing":4,
> "i64_thing":4
> },
> {
> "string_thing":"Hello2",
> "byte_thing":2,
> "i32_thing":2,
> "i64_thing":2
> }
> ]
> },
> "undefined":{
> "userMap":null,
> "xtructs":null
> }
> },
> "2":{
> "6":{
> "userMap":null,
> "xtructs":null
> }
> }
> }
> {code}
> on my code it also happens with 3 or more structures, only the first one is
> read, the second is "undefined" and the rest is gone!
> ps.: I'm submitting the patch for the unit test. I had a quick look on the
> code but could find anything yet and won't have time in the next weeks...
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (THRIFT-1238) Thrift JS client cannot read map of structures
Thrift JS client cannot read map of structures
--
Key: THRIFT-1238
URL: https://issues.apache.org/jira/browse/THRIFT-1238
Project: Thrift
Issue Type: Bug
Components: JavaScript - Compiler, JavaScript - Library
Affects Versions: 0.6.1
Reporter: Henrique Mendonca
Apparently we have a problem reading map of structures, only one item is been
read and the other come as undefined in the result map on the client side.
I was having this with some complex maps and notice that the test case
'testInsanity' was quite similar to my case but was actually been tested at
all. Then checking its result I could see that's it actually a general problem.
The server sends 2 elements:
{code}
{
"1":{
"3":{
"userMap":{
"8":8,
"5":5
},
"xtructs":[{
"string_thing":"Goodbye4",
"byte_thing":4,
"i32_thing":4,
"i64_thing":4
},
{
"string_thing":"Hello2",
"byte_thing":2,
"i32_thing":2,
"i64_thing":2
}
]
},
"2":{
"userMap":{
"8":8,
"5":5
},
"xtructs":[{
"string_thing":"Goodbye4",
"byte_thing":4,
"i32_thing":4,
"i64_thing":4
},
{
"string_thing":"Hello2",
"byte_thing":2,
"i32_thing":2,
"i64_thing":2
}
]
}
},
"2":{
"6":{
"userMap":null,
"xtructs":null
}
}
}
{code}
but we can only read 1:
{code}
{
"1":{
"2":{
"userMap":{
"8":8,
"5":5
},
"xtructs":[{
"string_thing":"Goodbye4",
"byte_thing":4,
"i32_thing":4,
"i64_thing":4
},
{
"string_thing":"Hello2",
"byte_thing":2,
"i32_thing":2,
"i64_thing":2
}
]
},
"undefined":{
"userMap":null,
"xtructs":null
}
},
"2":{
"6":{
"userMap":null,
"xtructs":null
}
}
}
{code}
on my code it also happens with 3 or more structures, only the first one is
read, the second is "undefined" and the rest is gone!
ps.: I'm submitting the patch for the unit test. I had a quick look on the code
but could find anything yet and won't have time in the next weeks...
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (THRIFT-1232) JavaScript TException should be a constructor function
[
https://issues.apache.org/jira/browse/THRIFT-1232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13060658#comment-13060658
]
Henrique Mendonca commented on THRIFT-1232:
---
actually... following THRIFT-724 and
https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Error , I
think it shouldn't inherit TException at all...
Perhaps extend it from Error like MDN suggests?
DerivedException = function(args) {
this.prototype = Error.prototype;
this.name = 'DerivedException';
...
}
then you could even get rid of Thrift.inherits() and Thrift.TException on
Thrift.js all together.
> JavaScript TException should be a constructor function
> --
>
> Key: THRIFT-1232
> URL: https://issues.apache.org/jira/browse/THRIFT-1232
> Project: Thrift
> Issue Type: Bug
> Components: JavaScript - Library
>Reporter: Pascal Bach
>Priority: Minor
> Labels: exception-handling, js
>
> The JavaScript TException is declared as an object with a prototype property
> assigned to it.
> It should be declared as a constructor function with a prototype. Otherwise
> exceptions derived from TException using Thrift.inherits are not instances of
> TException.
> Example:
> function DerivedException() {};
> Thrift.inherits(DerivedException, Thrift.TException);
> var ex = new DerivedException();
> ex instanceof Thrift.TException // => Error as TException is not a function
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (THRIFT-1232) JavaScript TException should be a constructor function
[
https://issues.apache.org/jira/browse/THRIFT-1232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13060457#comment-13060457
]
Henrique Mendonca commented on THRIFT-1232:
---
+1
the current TException "class" is indeed quite odd...
could you submit a patch?
thanks
> JavaScript TException should be a constructor function
> --
>
> Key: THRIFT-1232
> URL: https://issues.apache.org/jira/browse/THRIFT-1232
> Project: Thrift
> Issue Type: Bug
> Components: JavaScript - Library
>Reporter: Pascal Bach
>Priority: Minor
> Labels: exception-handling, js
>
> The JavaScript TException is declared as an object with a prototype property
> assigned to it.
> It should be declared as a constructor function with a prototype. Otherwise
> exceptions derived from TException using Thrift.inherits are not instances of
> TException.
> Example:
> function DerivedException() {};
> Thrift.inherits(DerivedException, Thrift.TException);
> var ex = new DerivedException();
> ex instanceof Thrift.TException // => Error as TException is not a function
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (THRIFT-1214) JavaScript constructor does not accept object properties
[
https://issues.apache.org/jira/browse/THRIFT-1214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13052505#comment-13052505
]
Henrique Mendonca commented on THRIFT-1214:
---
yeah, thanks Pascal, I've seen that before but end up not fixing it.
I'm using (args.value !== undefined) on this patch but (args.value != null) is
also an option, faster?
> JavaScript constructor does not accept object properties
>
>
> Key: THRIFT-1214
> URL: https://issues.apache.org/jira/browse/THRIFT-1214
> Project: Thrift
> Issue Type: Bug
> Components: JavaScript - Compiler
>Reporter: Pascal Bach
>Assignee: Henrique Mendonca
> Labels: javascript
> Attachments: THRIFT-1214-args-constructor.patch
>
>
> When you give a constructor function a set of default parameters they don't
> get assigned to the object correctly.
> The reason lies in the generated code:
> MyStruct = function(args) {
> this.value = null;
> if (args) {
> if (!args.value) {
> this.value = args.value;
> }
> }
> };
> The check for results !args.value causes that the value to be only set if it
> is undefined.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (THRIFT-1214) JavaScript constructor does not accept object properties
[
https://issues.apache.org/jira/browse/THRIFT-1214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henrique Mendonca updated THRIFT-1214:
--
Attachment: THRIFT-1214-args-constructor.patch
> JavaScript constructor does not accept object properties
>
>
> Key: THRIFT-1214
> URL: https://issues.apache.org/jira/browse/THRIFT-1214
> Project: Thrift
> Issue Type: Bug
> Components: JavaScript - Compiler
>Reporter: Pascal Bach
>Assignee: Henrique Mendonca
> Labels: javascript
> Attachments: THRIFT-1214-args-constructor.patch
>
>
> When you give a constructor function a set of default parameters they don't
> get assigned to the object correctly.
> The reason lies in the generated code:
> MyStruct = function(args) {
> this.value = null;
> if (args) {
> if (!args.value) {
> this.value = args.value;
> }
> }
> };
> The check for results !args.value causes that the value to be only set if it
> is undefined.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (THRIFT-1214) JavaScript constructor does not accept object properties
[
https://issues.apache.org/jira/browse/THRIFT-1214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henrique Mendonca reassigned THRIFT-1214:
-
Assignee: Henrique Mendonca
> JavaScript constructor does not accept object properties
>
>
> Key: THRIFT-1214
> URL: https://issues.apache.org/jira/browse/THRIFT-1214
> Project: Thrift
> Issue Type: Bug
> Components: JavaScript - Compiler
>Reporter: Pascal Bach
>Assignee: Henrique Mendonca
> Labels: javascript
>
> When you give a constructor function a set of default parameters they don't
> get assigned to the object correctly.
> The reason lies in the generated code:
> MyStruct = function(args) {
> this.value = null;
> if (args) {
> if (!args.value) {
> this.value = args.value;
> }
> }
> };
> The check for results !args.value causes that the value to be only set if it
> is undefined.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
