[jira] [Commented] (THRIFT-2945) Implement support for Rust language
[ https://issues.apache.org/jira/browse/THRIFT-2945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15865263#comment-15865263 ] Tony Przygienda commented on THRIFT-2945: - for 5. I finally found the PassThru solution to mask a richer implementation of the transport. I guess it works but it surely ain't easy to figure out ... > Implement support for Rust language > --- > > Key: THRIFT-2945 > URL: https://issues.apache.org/jira/browse/THRIFT-2945 > Project: Thrift > Issue Type: New Feature > Components: Rust - Compiler, Rust - Library >Reporter: Maksim Golov >Assignee: Allen George > Fix For: 0.11.0 > > > Work on implementing support for Rust is in progress: > https://github.com/maximg/thrift by Simon Génier and myself. > It will probably take quite some time to complete. Please keep us updated if > there are changes related to our work. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (THRIFT-2945) Implement support for Rust language
[ https://issues.apache.org/jira/browse/THRIFT-2945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15865159#comment-15865159 ] Tony Przygienda commented on THRIFT-2945: - 1. OK, I named it serializable since that's what the functions do. TThriftType may imply many other things ... I have already my own traits called TThriftXXX ... Observe that Rust lives off traits, it's very common to add them to structs ... 2. worked all fine with all the tests so please give me a min test you think may break on the hash. Otherwise maybe a knob under rust code generation ... 3. well, a method values() is a runtime thing which won't help. A simple example of trivial defaults one can generate under https://is.gd/bvkaey You can only generate it via macros, nothing else. And people do NOT have to use the macros, they just compile away ... I find it extremely helpful for my work here, the special enum treatement is necessary due to Rust macro restrictions ... 4. concrete example is that I have a module and within it the mod models where I want my thrift files to. I just run a small makefile in the models directory > all: encoding.rs routingtable.rs common.rs > *.rs: common.rs Makefile > %.rs: %.thrift > $(THRIFT_COMPILER) -I $(CURDIR)/common --gen rs --out $(CURDIR) $< this needs namespace * models on top so all the imports are correctly generated, otherwise the assumption is that models are in the top which is unscalable. Works a charm OK, will fix the `rust_safe_case` ... Formatting is the XCode setup, don't know where to twiddle it ... :-/ Any idea? Otherwise need surf web ... 5. The implementation of the transport/protocol is now very convoluted. The TTransport embedded in Rc Implement support for Rust language > --- > > Key: THRIFT-2945 > URL: https://issues.apache.org/jira/browse/THRIFT-2945 > Project: Thrift > Issue Type: New Feature > Components: Rust - Compiler, Rust - Library >Reporter: Maksim Golov >Assignee: Allen George > Fix For: 0.11.0 > > > Work on implementing support for Rust is in progress: > https://github.com/maximg/thrift by Simon Génier and myself. > It will probably take quite some time to complete. Please keep us updated if > there are changes related to our work. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (THRIFT-4089) Several issues with generated Python code: TFrozenDict, _fast_encode
Manasi Vartak created THRIFT-4089: - Summary: Several issues with generated Python code: TFrozenDict, _fast_encode Key: THRIFT-4089 URL: https://issues.apache.org/jira/browse/THRIFT-4089 Project: Thrift Issue Type: Bug Affects Versions: 0.10.0 Environment: Python 2.7. OS-X Reporter: Manasi Vartak When you generate Python sources for a simple thrift file (e.g. Thrift tutorial from https://thrift.apache.org/tutorial/py will also repro erros), errors are thrown while running the PythonServer and PythonClient. 1. When running the vanilla PythonServer, I get the following error: File "gen-py/shared/SharedService.py", line 9, in from thrift.Thrift import TType, TMessageType, TFrozenDict, TException, TApplicationException ImportError: cannot import name TFrozenDict I see this error consistently for all generated thrift files. The error disappears on removing TFrozenDict from the generated files (it is not used anywhere in the file). 2. When running the vanilla PythonClient (the server is now running after the above fix), I get the following error: File "PythonClient.py", line 51, in main client.ping() File "gen-py/tutorial/Calculator.py", line 73, in ping self.send_ping() File "gen-py/tutorial/Calculator.py", line 79, in send_ping args.write(self._oprot) File "gen-py/tutorial/Calculator.py", line 297, in write if oprot._fast_encode is not None and self.thrift_spec is not None: AttributeError: TBinaryProtocol instance has no attribute '_fast_encode' I am not sure why this error is being thrown/what can be done to fix it. These two errors, and mainly the latter one, are rendering the Server/Client un-usable. Is this a known issue? And how do you recommend working around it? -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Reopened] (THRIFT-4088) System.out in happy path
[
https://issues.apache.org/jira/browse/THRIFT-4088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King, III reopened THRIFT-4088:
Assignee: James E. King, III
> System.out in happy path
>
>
> Key: THRIFT-4088
> URL: https://issues.apache.org/jira/browse/THRIFT-4088
> Project: Thrift
> Issue Type: Improvement
>Reporter: Edward Capriolo
>Assignee: James E. King, III
>
> ./lib/java/src/org/apache/thrift/TServiceClient.java
> {noformat}
> protected void receiveBase(TBase result, String methodName) throws
> TException {
> TMessage msg = iprot_.readMessageBegin();
> if (msg.type == TMessageType.EXCEPTION) {
> TApplicationException x = new TApplicationException();
> x.read(iprot_);
> iprot_.readMessageEnd();
> throw x;
> }
> System.out.format("Received %d%n", msg.seqid);
> if (msg.seqid != seqid_) {
> throw new TApplicationException(TApplicationException.BAD_SEQUENCE_ID,
> String.format("%s failed: out of sequence response: expected %d but
> got %d", methodName, seqid_, msg.seqid));
> }
> result.read(iprot_);
> iprot_.readMessageEnd();
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (THRIFT-4088) System.out in happy path
[
https://issues.apache.org/jira/browse/THRIFT-4088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King, III closed THRIFT-4088.
--
> System.out in happy path
>
>
> Key: THRIFT-4088
> URL: https://issues.apache.org/jira/browse/THRIFT-4088
> Project: Thrift
> Issue Type: Improvement
>Reporter: Edward Capriolo
>Assignee: James E. King, III
>
> ./lib/java/src/org/apache/thrift/TServiceClient.java
> {noformat}
> protected void receiveBase(TBase result, String methodName) throws
> TException {
> TMessage msg = iprot_.readMessageBegin();
> if (msg.type == TMessageType.EXCEPTION) {
> TApplicationException x = new TApplicationException();
> x.read(iprot_);
> iprot_.readMessageEnd();
> throw x;
> }
> System.out.format("Received %d%n", msg.seqid);
> if (msg.seqid != seqid_) {
> throw new TApplicationException(TApplicationException.BAD_SEQUENCE_ID,
> String.format("%s failed: out of sequence response: expected %d but
> got %d", methodName, seqid_, msg.seqid));
> }
> result.read(iprot_);
> iprot_.readMessageEnd();
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (THRIFT-4088) System.out in happy path
[
https://issues.apache.org/jira/browse/THRIFT-4088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King, III resolved THRIFT-4088.
Resolution: Duplicate
Changed resolution to duplicate.
> System.out in happy path
>
>
> Key: THRIFT-4088
> URL: https://issues.apache.org/jira/browse/THRIFT-4088
> Project: Thrift
> Issue Type: Improvement
>Reporter: Edward Capriolo
>Assignee: James E. King, III
>
> ./lib/java/src/org/apache/thrift/TServiceClient.java
> {noformat}
> protected void receiveBase(TBase result, String methodName) throws
> TException {
> TMessage msg = iprot_.readMessageBegin();
> if (msg.type == TMessageType.EXCEPTION) {
> TApplicationException x = new TApplicationException();
> x.read(iprot_);
> iprot_.readMessageEnd();
> throw x;
> }
> System.out.format("Received %d%n", msg.seqid);
> if (msg.seqid != seqid_) {
> throw new TApplicationException(TApplicationException.BAD_SEQUENCE_ID,
> String.format("%s failed: out of sequence response: expected %d but
> got %d", methodName, seqid_, msg.seqid));
> }
> result.read(iprot_);
> iprot_.readMessageEnd();
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (THRIFT-4088) System.out in happy path
[
https://issues.apache.org/jira/browse/THRIFT-4088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King, III closed THRIFT-4088.
--
> System.out in happy path
>
>
> Key: THRIFT-4088
> URL: https://issues.apache.org/jira/browse/THRIFT-4088
> Project: Thrift
> Issue Type: Improvement
>Reporter: Edward Capriolo
>
> ./lib/java/src/org/apache/thrift/TServiceClient.java
> {noformat}
> protected void receiveBase(TBase result, String methodName) throws
> TException {
> TMessage msg = iprot_.readMessageBegin();
> if (msg.type == TMessageType.EXCEPTION) {
> TApplicationException x = new TApplicationException();
> x.read(iprot_);
> iprot_.readMessageEnd();
> throw x;
> }
> System.out.format("Received %d%n", msg.seqid);
> if (msg.seqid != seqid_) {
> throw new TApplicationException(TApplicationException.BAD_SEQUENCE_ID,
> String.format("%s failed: out of sequence response: expected %d but
> got %d", methodName, seqid_, msg.seqid));
> }
> result.read(iprot_);
> iprot_.readMessageEnd();
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (THRIFT-4083) maven-thrift-plugin doesn't work with thrift 0.10.0
[ https://issues.apache.org/jira/browse/THRIFT-4083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manasi Vartak resolved THRIFT-4083. --- Resolution: Information Provided > maven-thrift-plugin doesn't work with thrift 0.10.0 > --- > > Key: THRIFT-4083 > URL: https://issues.apache.org/jira/browse/THRIFT-4083 > Project: Thrift > Issue Type: Dependency upgrade >Affects Versions: 0.10.0 > Environment: Found on OS-X >Reporter: Manasi Vartak >Priority: Minor > > maven-thrift-plugin (0.1.10) doesn't work with thrift 0.10.0. > When compiling thrift sources (which worked with 0.9.3), the plugin throws > the following error: > [INFO] --- maven-thrift-plugin:0.1.11:compile (thrift-sources) @ project --- > [ERROR] thrift failed output: > [ERROR] thrift failed error: [FAILURE:generation:1] Error: unknown option > java:hashcode -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] thrift issue #1188: Check for joinable before attempting join in thread dest...
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1188 boost has a join_if_joinable wrapper for this, but I don't know what version it showed up in. It is better to avoid an exception when you can so this is good. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Resolved] (THRIFT-4088) System.out in happy path
[
https://issues.apache.org/jira/browse/THRIFT-4088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Capriolo resolved THRIFT-4088.
-
Resolution: Fixed
> System.out in happy path
>
>
> Key: THRIFT-4088
> URL: https://issues.apache.org/jira/browse/THRIFT-4088
> Project: Thrift
> Issue Type: Improvement
>Reporter: Edward Capriolo
>
> ./lib/java/src/org/apache/thrift/TServiceClient.java
> {noformat}
> protected void receiveBase(TBase result, String methodName) throws
> TException {
> TMessage msg = iprot_.readMessageBegin();
> if (msg.type == TMessageType.EXCEPTION) {
> TApplicationException x = new TApplicationException();
> x.read(iprot_);
> iprot_.readMessageEnd();
> throw x;
> }
> System.out.format("Received %d%n", msg.seqid);
> if (msg.seqid != seqid_) {
> throw new TApplicationException(TApplicationException.BAD_SEQUENCE_ID,
> String.format("%s failed: out of sequence response: expected %d but
> got %d", methodName, seqid_, msg.seqid));
> }
> result.read(iprot_);
> iprot_.readMessageEnd();
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (THRIFT-4088) System.out in happy path
[
https://issues.apache.org/jira/browse/THRIFT-4088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Capriolo updated THRIFT-4088:
Description:
./lib/java/src/org/apache/thrift/TServiceClient.java
{noformat}
protected void receiveBase(TBase result, String methodName) throws
TException {
TMessage msg = iprot_.readMessageBegin();
if (msg.type == TMessageType.EXCEPTION) {
TApplicationException x = new TApplicationException();
x.read(iprot_);
iprot_.readMessageEnd();
throw x;
}
System.out.format("Received %d%n", msg.seqid);
if (msg.seqid != seqid_) {
throw new TApplicationException(TApplicationException.BAD_SEQUENCE_ID,
String.format("%s failed: out of sequence response: expected %d but
got %d", methodName, seqid_, msg.seqid));
}
result.read(iprot_);
iprot_.readMessageEnd();
}
{noformat}
> System.out in happy path
>
>
> Key: THRIFT-4088
> URL: https://issues.apache.org/jira/browse/THRIFT-4088
> Project: Thrift
> Issue Type: Improvement
>Reporter: Edward Capriolo
>
> ./lib/java/src/org/apache/thrift/TServiceClient.java
> {noformat}
> protected void receiveBase(TBase result, String methodName) throws
> TException {
> TMessage msg = iprot_.readMessageBegin();
> if (msg.type == TMessageType.EXCEPTION) {
> TApplicationException x = new TApplicationException();
> x.read(iprot_);
> iprot_.readMessageEnd();
> throw x;
> }
> System.out.format("Received %d%n", msg.seqid);
> if (msg.seqid != seqid_) {
> throw new TApplicationException(TApplicationException.BAD_SEQUENCE_ID,
> String.format("%s failed: out of sequence response: expected %d but
> got %d", methodName, seqid_, msg.seqid));
> }
> result.read(iprot_);
> iprot_.readMessageEnd();
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (THRIFT-4088) System.out in happy path
Edward Capriolo created THRIFT-4088: --- Summary: System.out in happy path Key: THRIFT-4088 URL: https://issues.apache.org/jira/browse/THRIFT-4088 Project: Thrift Issue Type: Improvement Reporter: Edward Capriolo -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (THRIFT-2945) Implement support for Rust language
[
https://issues.apache.org/jira/browse/THRIFT-2945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15864893#comment-15864893
]
Allen George edited comment on THRIFT-2945 at 2/14/17 2:20 AM:
---
[~prz] - let me try to address these points individually.
# "Split the {{read_from_in_protocol}} and {{write_to_out_protocol}} as a
trait." This seems like a great idea. Perhaps it could be named {{TThriftType}}
to keep with the existing naming convention? I suggest submitting this as a PR
since it would be small and self-contained.
# "Auto-derive hash on generated types." Are you sure this works with types
that contain {{OrderedFloat}}? Thrift doubles (represented in Rust by floats,
not fixed-point integers) are the reason why I had to use {{BTreeMap}} and
{{BTreeSet}}, and was unable to auto-derive {{Hash}}. Perhaps I overlooked
something?
# Could you clarify why you need to change the enum and union code-generation?
From what I understand, your main requirement was getting a list of all defined
enum variants and associated values. Since we know the full list of variants
ahead from the thrift file we could simply add a {{values()}} method that
returns the information you need. Also, I specifically opted *not* to generate
macros since it adds another level of indirection that anybody debugging thrift
auto-gen code would have to reason about: they'd have to understand how the
thrift gets turned into a macro, the macro definition, and then the final rust
output.
# Finally, while I understand that you want to use the Thrift {{namespace}}
directive. Could you give me a concrete example of what you expect the output
to be? Would it be output to different directories, or would you output it to
the same directory and then rely on a manual step afterwards to move it to the
appropriate Rust module. (PS. Your patch has a bug: you forgot to
{{rust_safe_case}} the module name, and it will break on thrift modules that
already have underscores in them)
Another points: I looked at your branch, and noticed that your formatting is
inconsistent with the existing code (the existing code uses 2-space tabs).
was (Author: allengeorge):
[~prz] - let me try to address these points individually.
# "Split the {{read_from_in_protocol}} and {{write_to_out_protocol}} as a
trait." This seems like a great idea. Perhaps it could be named {{TThriftType}}
to keep with the existing naming convention? I suggest submitting this as a PR
since it would be small and self-contained.
# "Auto-derive hash on generated types." Are you sure this works with types
that contain {{OrderedFloat}}? Thrift doubles (represented in Rust by floats,
not fixed-point integers) are the reason why I had to use {{BTreeMap}} and
{{BTreeSet}}, and was unable to auto-derive {{Hash}}. Perhaps I overlooked
something?
# Could you clarify why you need to change the enum and union code-generation?
From what I understand, your main requirement was getting a list of all defined
enum variants and associated values. Since we know the full list of variants
ahead from the thrift file we could simply add a {{values()}} method that
returns the information you need. Also, I specifically opted *not* to use
generate macros since it adds another level of indirection that anybody
debugging thrift auto-gen code would have to reason about: they'd have to
understand how the thrift gets turned into a macro, the macro definition, and
then the final rust output.
# Finally, while I understand that you want to use the Thrift {{namespace}}
directive. Could you give me a concrete example of what you expect the output
to be? Would it be output to different directories, or would you output it to
the same directory and then rely on a manual step afterwards to move it to the
appropriate Rust module. (PS. Your patch has a bug: you forgot to
{{rust_safe_case}} the module name, and it will break on thrift modules that
already have underscores in them)
Another points: I looked at your branch, and noticed that your formatting is
inconsistent with the existing code (the existing code uses 2-space tabs).
> Implement support for Rust language
> ---
>
> Key: THRIFT-2945
> URL: https://issues.apache.org/jira/browse/THRIFT-2945
> Project: Thrift
> Issue Type: New Feature
> Components: Rust - Compiler, Rust - Library
>Reporter: Maksim Golov
>Assignee: Allen George
> Fix For: 0.11.0
>
>
> Work on implementing support for Rust is in progress:
> https://github.com/maximg/thrift by Simon Génier and myself.
> It will probably take quite some time to complete. Please keep us updated if
> there are changes related to our work.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (THRIFT-2945) Implement support for Rust language
[
https://issues.apache.org/jira/browse/THRIFT-2945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15864893#comment-15864893
]
Allen George edited comment on THRIFT-2945 at 2/14/17 2:20 AM:
---
[~prz] - let me try to address these points individually.
# "Split the {{read_from_in_protocol}} and {{write_to_out_protocol}} as a
trait." This seems like a great idea. Perhaps it could be named {{TThriftType}}
to keep with the existing naming convention? I suggest submitting this as a PR
since it would be small and self-contained.
# "Auto-derive hash on generated types." Are you sure this works with types
that contain {{OrderedFloat}}? Thrift doubles (represented in Rust by floats,
not fixed-point integers) are the reason why I had to use {{BTreeMap}} and
{{BTreeSet}}, and was unable to auto-derive {{Hash}}. Perhaps I overlooked
something?
# Could you clarify why you need to change the enum and union code-generation?
From what I understand, your main requirement was getting a list of all defined
enum variants and associated values. Since we know the full list of variants
ahead from the thrift file we could simply add a {{values()}} method that
returns the information you need. Also, I specifically opted *not* to generate
macros since it adds another level of indirection that anybody debugging thrift
auto-gen code would have to reason about: they'd have to understand how the
thrift gets turned into a macro, the macro definition, and then the final rust
output.
# Finally, while I understand that you want to use the Thrift {{namespace}}
directive, could you give me a concrete example of what you expect the output
to be? Would it be output to different directories, or would you output it to
the same directory and then rely on a manual step afterwards to move it to the
appropriate Rust module. (PS. Your patch has a bug: you forgot to
{{rust_safe_case}} the module name, and it will break on thrift modules that
already have underscores in them)
Another points: I looked at your branch, and noticed that your formatting is
inconsistent with the existing code (the existing code uses 2-space tabs).
was (Author: allengeorge):
[~prz] - let me try to address these points individually.
# "Split the {{read_from_in_protocol}} and {{write_to_out_protocol}} as a
trait." This seems like a great idea. Perhaps it could be named {{TThriftType}}
to keep with the existing naming convention? I suggest submitting this as a PR
since it would be small and self-contained.
# "Auto-derive hash on generated types." Are you sure this works with types
that contain {{OrderedFloat}}? Thrift doubles (represented in Rust by floats,
not fixed-point integers) are the reason why I had to use {{BTreeMap}} and
{{BTreeSet}}, and was unable to auto-derive {{Hash}}. Perhaps I overlooked
something?
# Could you clarify why you need to change the enum and union code-generation?
From what I understand, your main requirement was getting a list of all defined
enum variants and associated values. Since we know the full list of variants
ahead from the thrift file we could simply add a {{values()}} method that
returns the information you need. Also, I specifically opted *not* to generate
macros since it adds another level of indirection that anybody debugging thrift
auto-gen code would have to reason about: they'd have to understand how the
thrift gets turned into a macro, the macro definition, and then the final rust
output.
# Finally, while I understand that you want to use the Thrift {{namespace}}
directive. Could you give me a concrete example of what you expect the output
to be? Would it be output to different directories, or would you output it to
the same directory and then rely on a manual step afterwards to move it to the
appropriate Rust module. (PS. Your patch has a bug: you forgot to
{{rust_safe_case}} the module name, and it will break on thrift modules that
already have underscores in them)
Another points: I looked at your branch, and noticed that your formatting is
inconsistent with the existing code (the existing code uses 2-space tabs).
> Implement support for Rust language
> ---
>
> Key: THRIFT-2945
> URL: https://issues.apache.org/jira/browse/THRIFT-2945
> Project: Thrift
> Issue Type: New Feature
> Components: Rust - Compiler, Rust - Library
>Reporter: Maksim Golov
>Assignee: Allen George
> Fix For: 0.11.0
>
>
> Work on implementing support for Rust is in progress:
> https://github.com/maximg/thrift by Simon Génier and myself.
> It will probably take quite some time to complete. Please keep us updated if
> there are changes related to our work.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (THRIFT-2945) Implement support for Rust language
[
https://issues.apache.org/jira/browse/THRIFT-2945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15864893#comment-15864893
]
Allen George edited comment on THRIFT-2945 at 2/14/17 2:19 AM:
---
[~prz] - let me try to address these points individually.
# "Split the {{read_from_in_protocol}} and {{write_to_out_protocol}} as a
trait." This seems like a great idea. Perhaps it could be named {{TThriftType}}
to keep with the existing naming convention? I suggest submitting this as a PR
since it would be small and self-contained.
# "Auto-derive hash on generated types." Are you sure this works with types
that contain {{OrderedFloat}}? Thrift doubles (represented in Rust by floats,
not fixed-point integers) are the reason why I had to use {{BTreeMap}} and
{{BTreeSet}}, and was unable to auto-derive {{Hash}}. Perhaps I overlooked
something?
# Could you clarify why you need to change the enum and union code-generation?
From what I understand, your main requirement was getting a list of all defined
enum variants and associated values. Since we know the full list of variants
ahead from the thrift file we could simply add a {{values()}} method that
returns the information you need. Also, I specifically opted *not* to use
generate macros since it adds another level of indirection that anybody
debugging thrift auto-gen code would have to reason about: they'd have to
understand how the thrift gets turned into a macro, the macro definition, and
then the final rust output.
# Finally, while I understand that you want to use the Thrift {{namespace}}
directive. Could you give me a concrete example of what you expect the output
to be? Would it be output to different directories, or would you output it to
the same directory and then rely on a manual step afterwards to move it to the
appropriate Rust module. (PS. Your patch has a bug: you forgot to
{{rust_safe_case}} the module name, and it will break on thrift modules that
already have underscores in them)
Another points: I looked at your branch, and noticed that your formatting is
inconsistent with the existing code (the existing code uses 2-space tabs).
was (Author: allengeorge):
[~prz] - let me try to address these points individually.
# "Split the {{read_from_in_protocol}} and {{write_to_out_protocol}} as a
trait." This seems like a great idea. Perhaps it could be named {{TThriftType}}
to keep with the existing naming convention? I suggest submitting this as a PR
since it would be small and self-contained.
# "Auto-derive hash on generated types." Are you sure this works with types
that contain {{OrderedFloat}}? Thrift doubles (represented in Rust by floats,
not fixed-point integers) are the reason why I had to use {{BTreeMap}} and
{{BTreeSet}}, and was unable to auto-derive {{Hash}}. Perhaps I overlooked
something?
# Could you clarify why you need to change the enum and union code-generation?
From what I understand, your main requirement was getting a list of all defined
enum variants and associated values. Since we know the full list of variants
ahead from the thrift file we could simply add a {{values()}} method that
returns the information you need. Also note that I specifically opted *not* to
use generate macros since it adds another level of indirection that anybody
debugging thrift auto-gen code would have to reason about: they'd have to
understand how the thrift gets turned into a macro, the macro definition, and
then the final rust output.
# Finally, while I understand that you want to use the Thrift {{namespace}}
directive. Could you give me a concrete example of what you expect the output
to be? Would it be output to different directories, or would you output it to
the same directory and then rely on a manual step afterwards to move it to the
appropriate Rust module. (PS. Your patch has a bug: you forgot to
{{rust_safe_case}} the module name, and it will break on thrift modules that
already have underscores in them)
Another points: I looked at your branch, and noticed that your formatting is
inconsistent with the existing code (the existing code uses 2-space tabs).
> Implement support for Rust language
> ---
>
> Key: THRIFT-2945
> URL: https://issues.apache.org/jira/browse/THRIFT-2945
> Project: Thrift
> Issue Type: New Feature
> Components: Rust - Compiler, Rust - Library
>Reporter: Maksim Golov
>Assignee: Allen George
> Fix For: 0.11.0
>
>
> Work on implementing support for Rust is in progress:
> https://github.com/maximg/thrift by Simon Génier and myself.
> It will probably take quite some time to complete. Please keep us updated if
> there are changes related to our work.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (THRIFT-2945) Implement support for Rust language
[
https://issues.apache.org/jira/browse/THRIFT-2945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15864893#comment-15864893
]
Allen George commented on THRIFT-2945:
--
[~prz] - let me try to address these points individually.
# "Split the {{read_from_in_protocol}} and {{write_to_out_protocol}} as a
trait." This seems like a great idea. Perhaps it could be named {{TThriftType}}
to keep with the existing naming convention? I suggest submitting this as a PR
since it would be small and self-contained.
# "Auto-derive hash on generated types." Are you sure this works with types
that contain {{OrderedFloat}}? Thrift doubles (represented in Rust by floats,
not fixed-point integers) are the reason why I had to use {{BTreeMap}} and
{{BTreeSet}}, and was unable to auto-derive {{Hash}}. Perhaps I overlooked
something?
# Could you clarify why you need to change the enum and union code-generation?
From what I understand, your main requirement was getting a list of all defined
enum variants and associated values. Since we know the full list of variants
ahead from the thrift file we could simply add a {{values()}} method that
returns the information you need. Also note that I specifically opted *not* to
use generate macros since it adds another level of indirection that anybody
debugging thrift auto-gen code would have to reason about: they'd have to
understand how the thrift gets turned into a macro, the macro definition, and
then the final rust output.
# Finally, while I understand that you want to use the Thrift {{namespace}}
directive. Could you give me a concrete example of what you expect the output
to be? Would it be output to different directories, or would you output it to
the same directory and then rely on a manual step afterwards to move it to the
appropriate Rust module. (PS. Your patch has a bug: you forgot to
{{rust_safe_case}} the module name, and it will break on thrift modules that
already have underscores in them)
Another points: I looked at your branch, and noticed that your formatting is
inconsistent with the existing code (the existing code uses 2-space tabs).
> Implement support for Rust language
> ---
>
> Key: THRIFT-2945
> URL: https://issues.apache.org/jira/browse/THRIFT-2945
> Project: Thrift
> Issue Type: New Feature
> Components: Rust - Compiler, Rust - Library
>Reporter: Maksim Golov
>Assignee: Allen George
> Fix For: 0.11.0
>
>
> Work on implementing support for Rust is in progress:
> https://github.com/maximg/thrift by Simon Génier and myself.
> It will probably take quite some time to complete. Please keep us updated if
> there are changes related to our work.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] thrift issue #1188: Check for joinable before attempting join in thread dest...
Github user cgrebeld commented on the issue: https://github.com/apache/thrift/pull/1188 Thanks, Sorry for not being clear. As you said the exception was being thrown and caught, there was no incorrect behavior, I was just annoyed that the normal control flow entered a block marked "// We're really hosed." when I was debugging an unrelated issue. I'll be sure to follow the protocol next time, thanks for the advice. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (THRIFT-3859) Unix Domain Socket Support in Objective-C
[
https://issues.apache.org/jira/browse/THRIFT-3859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15864860#comment-15864860
]
ASF GitHub Bot commented on THRIFT-3859:
Github user jeking3 commented on the issue:
https://github.com/apache/thrift/pull/1031
To enable "make cross" support you can follow the pattern in
test/tests.json to add the "domain" transport to your cocoa test. Your cocoa
test_client needs to understand that transport and create the correct kind of
client, etc.
> Unix Domain Socket Support in Objective-C
> -
>
> Key: THRIFT-3859
> URL: https://issues.apache.org/jira/browse/THRIFT-3859
> Project: Thrift
> Issue Type: Improvement
> Components: Cocoa - Library
>Affects Versions: 0.10.0
>Reporter: Chris Vasselli
>Priority: Minor
>
> I would like to be able to use Unix Domain Sockets as the transport to
> communicate between different processes on a single machine. There seems to
> be support in the C++ and Python libraries (the two other languages used in
> my project), but no support in Objective-C.
> Proposed server interface:
> {{TSocketServer *server = [[TSocketServer alloc]
> initWithPath:@"/path/to/pipe" protocolFactory:protocolFactory
> processorFactory:processorFactory];}}
> Proposed client interface:
> {{TSocketTransport *socket = [[TSocketTransport alloc]
> initWithPath:@"/path/to/pipe"];}}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] thrift issue #1031: THRIFT-3859: Unix Domain Socket Support in Objective-C
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1031 To enable "make cross" support you can follow the pattern in test/tests.json to add the "domain" transport to your cocoa test. Your cocoa test_client needs to understand that transport and create the correct kind of client, etc. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
Downstream packaging
Hi, I'm trying to take over the downstream packaging for thrift in Fedora and EPEL, and having some difficulties to get everything built correctly. The previous package maintainer had packaged 0.9.1, but had a number of patches and supplemental source files that were needed to fix some things. In particular, the official source tarball release does not contain everything needed to build the project. It is missing the bootstrap.sh file, so we're having to pull that directly from the repository mirror on GitHub in order to build from source. This is problematic... even your own build instructions say to use this file to build from source: http://thrift.apache.org/docs/BuildingFromSource Is this a known issue? Will future thrift releases contain the full source code to build from, or will it continue to ship only generated sources to bootstrap the build, due to an intentional choice? The next problem area is that the previous maintainer had been building libfb303 from the contrib directory and shipping it as a sub-package (secondary RPM built from the same source). Now, I'm not sure what fb303 is (none of my projects have ever used it), but we had previously been retrieving it's corresponding POM file from the Maven Central repository, since it doesn't appear to be included in the tarball (at least for 0.9.1). Now that we're on 0.10.0, I figured I'd have to do the same, but it looks like nobody ever deployed fb303 0.10.0 to Maven Central on the last release. Is this something you're planning on doing? Is this even an actively maintained contrib project? Maybe I should just stop packaging it, and stick to packaging the main thrift bits. If there's any interest in testing, or improving the Fedora packaging for thrift, I welcome the assistance from the existing thrift developers. Downstream packaging is a great way to make thrift available to a wider audience, as well as a great way to understand what you need to do to improve the build system. It's also a great way to ensure integration with the latest build tools and runtime libraries that desktop users are likely to have on their modern OS installs. Thanks! -- Christopher
[jira] [Commented] (THRIFT-2364) OCaml: Use Oasis exclusively for build process
[ https://issues.apache.org/jira/browse/THRIFT-2364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15864688#comment-15864688 ] James E. King, III commented on THRIFT-2364: [~seliopou] I have been able to add ocaml to the ubuntu and debian dockerfiles, and your patch allows lib/ocaml to build. I would like to ask for your help to complete the process by integrating the ocaml language into "make cross" testing and the standard autoconf build (and cmake build if you can manage). Any chance you can assist with this? > OCaml: Use Oasis exclusively for build process > -- > > Key: THRIFT-2364 > URL: https://issues.apache.org/jira/browse/THRIFT-2364 > Project: Thrift > Issue Type: Improvement > Components: Build Process, OCaml - Library > Environment: All environments >Reporter: Spiros Eliopoulos >Assignee: Spiros Eliopoulos >Priority: Minor > Attachments: THRIFT-2364.patch > > > The OCaml library currently contains custom makefiles, as well as an _oasis > configuration file that will generate a configuration script and Makefile. > The preferred method of the community for building OCaml libraries is to use > Oasis, so the other files should be dropped in favor of that. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (THRIFT-4087) Spurious exception destroying TThreadedServer because of incorrect join() call
[ https://issues.apache.org/jira/browse/THRIFT-4087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III resolved THRIFT-4087. Resolution: Fixed Fix Version/s: 0.11.0 > Spurious exception destroying TThreadedServer because of incorrect join() call > -- > > Key: THRIFT-4087 > URL: https://issues.apache.org/jira/browse/THRIFT-4087 > Project: Thrift > Issue Type: Bug > Components: C++ - Library >Affects Versions: 0.10.0 >Reporter: James E. King, III >Assignee: James E. King, III > Fix For: 0.11.0 > > > Opened this for https://github.com/apache/thrift/pull/1188/files -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] thrift pull request #1188: Check for joinable before attempting join in thre...
Github user asfgit closed the pull request at: https://github.com/apache/thrift/pull/1188 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Created] (THRIFT-4087) Spurious exception destroying TThreadedServer because of incorrect join() call
James E. King, III created THRIFT-4087: -- Summary: Spurious exception destroying TThreadedServer because of incorrect join() call Key: THRIFT-4087 URL: https://issues.apache.org/jira/browse/THRIFT-4087 Project: Thrift Issue Type: Bug Components: C++ - Library Affects Versions: 0.10.0 Reporter: James E. King, III Assignee: James E. King, III Opened this for https://github.com/apache/thrift/pull/1188/files -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (THRIFT-1805) Thrift should not swallow ALL exceptions
[ https://issues.apache.org/jira/browse/THRIFT-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15864602#comment-15864602 ] ASF GitHub Bot commented on THRIFT-1805: Github user ctubbsii commented on a diff in the pull request: https://github.com/apache/thrift/pull/1186#discussion_r100917042 --- Diff: compiler/cpp/src/thrift/generate/t_java_generator.cc --- @@ -5265,6 +5274,9 @@ THRIFT_REGISTER_GENERATOR( "android_legacy: Do not use java.io.IOException(throwable) (available for Android 2.3 and " "above).\n" "option_type: Wrap optional fields in an Option type.\n" +"handle_runtime_exceptions:\n" +" Generated services will handle RuntimeException as " --- End diff -- Okay, I updated the docs based on my simplified wording above, but also with an explanation of the default behavior. > Thrift should not swallow ALL exceptions > > > Key: THRIFT-1805 > URL: https://issues.apache.org/jira/browse/THRIFT-1805 > Project: Thrift > Issue Type: Bug > Components: Java - Compiler, Java - Library >Affects Versions: 0.9 >Reporter: Diwaker Gupta >Assignee: Diwaker Gupta > Attachments: THRIFT-1805.patch > > > In Thrift 0.8.0, Thrift generated Java code did not swallow application > exceptions. As a result of THRIFT-1658, this behavior changed in 0.9.0 and > now the generated code swallows ALL application exceptions (via > ProcessFunction). Apparently this was the behavior in Thrift 0.6.0 and while > I see the rationale, it is breaking our applications. > Our code relies on the fact that exceptions can propagate outside of Thrift > for certain things (e.g., to aggressively drop connections for clients that > send invalid/malformed requests). ProcessFunction makes it near impossible to > do this -- not only does it swallow the exception, it also loses all > information about the original exception and just writes out a generic > TApplicationException. > IMO ProcessFunction should only catch TException. If the application code > wants to use other exceptions for some reason (in particular, Errors and > RuntimeExceptions), Thrift shouldn't prevent that. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] thrift pull request #1186: THRIFT-1805 Provide option for handling RTEs
Github user ctubbsii commented on a diff in the pull request: https://github.com/apache/thrift/pull/1186#discussion_r100917042 --- Diff: compiler/cpp/src/thrift/generate/t_java_generator.cc --- @@ -5265,6 +5274,9 @@ THRIFT_REGISTER_GENERATOR( "android_legacy: Do not use java.io.IOException(throwable) (available for Android 2.3 and " "above).\n" "option_type: Wrap optional fields in an Option type.\n" +"handle_runtime_exceptions:\n" +" Generated services will handle RuntimeException as " --- End diff -- Okay, I updated the docs based on my simplified wording above, but also with an explanation of the default behavior. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (THRIFT-1805) Thrift should not swallow ALL exceptions
[ https://issues.apache.org/jira/browse/THRIFT-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15864547#comment-15864547 ] ASF GitHub Bot commented on THRIFT-1805: Github user keith-turner commented on a diff in the pull request: https://github.com/apache/thrift/pull/1186#discussion_r10097 --- Diff: compiler/cpp/src/thrift/generate/t_java_generator.cc --- @@ -5265,6 +5274,9 @@ THRIFT_REGISTER_GENERATOR( "android_legacy: Do not use java.io.IOException(throwable) (available for Android 2.3 and " "above).\n" "option_type: Wrap optional fields in an Option type.\n" +"handle_runtime_exceptions:\n" +" Generated services will handle RuntimeException as " --- End diff -- I don't think we need to mention anything about the client side w.r.t to TTransportException. Saying anything about the client side is hard because of all the different language implementations. However this code is focused on generating a java server, so we can say what the java server will do. The java server will either send TApplicationException or close the connection depending on this setting. > Thrift should not swallow ALL exceptions > > > Key: THRIFT-1805 > URL: https://issues.apache.org/jira/browse/THRIFT-1805 > Project: Thrift > Issue Type: Bug > Components: Java - Compiler, Java - Library >Affects Versions: 0.9 >Reporter: Diwaker Gupta >Assignee: Diwaker Gupta > Attachments: THRIFT-1805.patch > > > In Thrift 0.8.0, Thrift generated Java code did not swallow application > exceptions. As a result of THRIFT-1658, this behavior changed in 0.9.0 and > now the generated code swallows ALL application exceptions (via > ProcessFunction). Apparently this was the behavior in Thrift 0.6.0 and while > I see the rationale, it is breaking our applications. > Our code relies on the fact that exceptions can propagate outside of Thrift > for certain things (e.g., to aggressively drop connections for clients that > send invalid/malformed requests). ProcessFunction makes it near impossible to > do this -- not only does it swallow the exception, it also loses all > information about the original exception and just writes out a generic > TApplicationException. > IMO ProcessFunction should only catch TException. If the application code > wants to use other exceptions for some reason (in particular, Errors and > RuntimeExceptions), Thrift shouldn't prevent that. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] thrift pull request #1186: THRIFT-1805 Provide option for handling RTEs
Github user keith-turner commented on a diff in the pull request: https://github.com/apache/thrift/pull/1186#discussion_r10097 --- Diff: compiler/cpp/src/thrift/generate/t_java_generator.cc --- @@ -5265,6 +5274,9 @@ THRIFT_REGISTER_GENERATOR( "android_legacy: Do not use java.io.IOException(throwable) (available for Android 2.3 and " "above).\n" "option_type: Wrap optional fields in an Option type.\n" +"handle_runtime_exceptions:\n" +" Generated services will handle RuntimeException as " --- End diff -- I don't think we need to mention anything about the client side w.r.t to TTransportException. Saying anything about the client side is hard because of all the different language implementations. However this code is focused on generating a java server, so we can say what the java server will do. The java server will either send TApplicationException or close the connection depending on this setting. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] thrift issue #1187: Review for pull up of RUST extended namespace support, a...
Github user przygienda commented on the issue: https://github.com/apache/thrift/pull/1187 OK, finished. The patch does * improve the namespace support by allowing to nest Thrift models inside a package now * moves the reading/writing into a proper trait so models can be differentiated and generics written over them * adds macro definitions to all generated types which allows the package generating the code to e.g. generate code over model definitions, e.g. to derive custom traits via macrosthat use the internal structure of enum/struct/union such as custom defaults, statistics and so on ... --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Updated] (THRIFT-4084) Improve SSL security in thrift by adding a make cross client that checks to make sure SSLv3 protocol cannot be negotiated
[ https://issues.apache.org/jira/browse/THRIFT-4084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III updated THRIFT-4084: --- Description: Following code review discussions in THRIFT-3369, and seeing THRIFT-3165 in the backlog, I want to add a make cross "language" which isn't a language at all, but a test that checks to see if it is possible to negotiate at various SSL/TLS protocol versions. This would be a client-only test, likely just a bash script that leverages the openssl client and command line options to connect to a test server and see if it handshakes and negotiates protocol successfully. Without THRIFT-3165 implemented, it will ensure: * Can handshake using the universal SSLv23 context, however cannot negotiate SSLv3 * Can negotiate TLSv1.0, TLSv1.1, and TLSv1.2 With THRIFT-3165 it needs to change to ensure: * Can handshake using TLSv1.2 but not any other version The solution I came up with was to add a new client called "secure" to make crosstest. test_secure is a simple bash script that checks the appropriate rules above (the ones without THRIFT-3165, since it is not done), and I added "secure" to the list of cross test "languages" in the top level configure script. was: Following code review discussions in THRIFT-3369, and seeing THRIFT-3165 in the backlog, I want to add a make cross "language" which isn't a language at all, but a test that checks to see if it is possible to negotiate at various SSL/TLS protocol versions. This would be a client-only test, likely just a bash script that leverages the openssl client and command line options to connect to a test server and see if it handshakes and negotiates protocol successfully. Without THRIFT-3165 implemented, it will ensure: * Can handshake using the universal SSLv23 context, however cannot negotiate SSLv3 * Can negotiate TLSv1.0, TLSv1.1, and TLSv1.2 With THRIFT-3165 it needs to change to ensure: * Can handshake using TLSv1.2 but not any other version > Improve SSL security in thrift by adding a make cross client that checks to > make sure SSLv3 protocol cannot be negotiated > - > > Key: THRIFT-4084 > URL: https://issues.apache.org/jira/browse/THRIFT-4084 > Project: Thrift > Issue Type: Improvement > Components: Test Suite >Affects Versions: 0.10.0 > Environment: Ubuntu Dockerfile >Reporter: James E. King, III >Assignee: James E. King, III > Labels: cross-validation, security, ssl, tls > > Following code review discussions in THRIFT-3369, and seeing THRIFT-3165 in > the backlog, I want to add a make cross "language" which isn't a language at > all, but a test that checks to see if it is possible to negotiate at various > SSL/TLS protocol versions. This would be a client-only test, likely just a > bash script that leverages the openssl client and command line options to > connect to a test server and see if it handshakes and negotiates protocol > successfully. > Without THRIFT-3165 implemented, it will ensure: > * Can handshake using the universal SSLv23 context, however cannot negotiate > SSLv3 > * Can negotiate TLSv1.0, TLSv1.1, and TLSv1.2 > With THRIFT-3165 it needs to change to ensure: > * Can handshake using TLSv1.2 but not any other version > The solution I came up with was to add a new client called "secure" to make > crosstest. test_secure is a simple bash script that checks the appropriate > rules above (the ones without THRIFT-3165, since it is not done), and I added > "secure" to the list of cross test "languages" in the top level configure > script. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (THRIFT-1805) Thrift should not swallow ALL exceptions
[ https://issues.apache.org/jira/browse/THRIFT-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15864504#comment-15864504 ] James E. King, III commented on THRIFT-1805: [~jensg], [~nsuke], [~roger.meier] given you had significant input to this one, you should consider reviewing the solution and approve the pull request on github if you would like it to merge. There have been two approvals already. > Thrift should not swallow ALL exceptions > > > Key: THRIFT-1805 > URL: https://issues.apache.org/jira/browse/THRIFT-1805 > Project: Thrift > Issue Type: Bug > Components: Java - Compiler, Java - Library >Affects Versions: 0.9 >Reporter: Diwaker Gupta >Assignee: Diwaker Gupta > Attachments: THRIFT-1805.patch > > > In Thrift 0.8.0, Thrift generated Java code did not swallow application > exceptions. As a result of THRIFT-1658, this behavior changed in 0.9.0 and > now the generated code swallows ALL application exceptions (via > ProcessFunction). Apparently this was the behavior in Thrift 0.6.0 and while > I see the rationale, it is breaking our applications. > Our code relies on the fact that exceptions can propagate outside of Thrift > for certain things (e.g., to aggressively drop connections for clients that > send invalid/malformed requests). ProcessFunction makes it near impossible to > do this -- not only does it swallow the exception, it also loses all > information about the original exception and just writes out a generic > TApplicationException. > IMO ProcessFunction should only catch TException. If the application code > wants to use other exceptions for some reason (in particular, Errors and > RuntimeExceptions), Thrift shouldn't prevent that. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (THRIFT-4060) Thrift printTo ostream overload mechanism breaks down when types are nested
[
https://issues.apache.org/jira/browse/THRIFT-4060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15864496#comment-15864496
]
ASF GitHub Bot commented on THRIFT-4060:
Github user asfgit closed the pull request at:
https://github.com/apache/thrift/pull/1172
> Thrift printTo ostream overload mechanism breaks down when types are nested
> ---
>
> Key: THRIFT-4060
> URL: https://issues.apache.org/jira/browse/THRIFT-4060
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Compiler
>Affects Versions: 0.9.3, 0.10.0
> Environment: Ubuntu 14.04 LTS
>Reporter: James E. King, III
>Assignee: James E. King, III
> Fix For: 0.11.0
>
>
> I'm in the middle of converting a project that provides some ostream
> operators (for logging purposes) for a number of thrift structures. The
> project was using 0.8.0 and in 0.9.3 some ostream operator overloads were
> added with THRIFT-3336. The solution that was provided here runs into
> complications if a thrift structure is contained within another one. Take
> this simple example:
> h4. Thrift
> {noformat}
> namespace cpp example.detail
> struct Lower {
>1: binary lowerBinary
> }
> struct Higher {
> 1: set lowers
> }
> {noformat}
> h4. C++
> {noformat}
> namespace example {
> class MyLower : public detail::Lower
> {
> virtual void printTo(std::ostream& os) const override;
> }
> class MyHigher : public detail::Higher
> {
> virtual void printTo(std::ostream& os) const override
> {
> os << lowers;
> // here's the problem, lowers is a set when it
> serializes in,
> // not a set, so I cannot override it...
> }
> }
> }
> {noformat}
> I'm considering adding an annotation to the thrift IDL that the compiler will
> recognize that allows someone to say, "I am going to provide my own
> operator<< for this structure, don't generate one". This would replace the
> printTo mechanism that was added in THRIFT-3336.
> Here is an example:
> {noformat}
> namespace cpp example.detail
> struct MyLower {
>1: binary lowerBinary
> } (cpp.customostream)
> struct MyHigher {
> 1: set lowers
> }
> {noformat}
> The annotation {{cpp.customostream}} (or the compiler option {{--gen
> cpp:no_ostream_operators}} for global effect) tells the compiler to emit only
> the declaration of the {{operator <<}} but does not emit a definition
> (implementation). It would be up to the implementation building against the
> generated code to provide an operator << if such an operator is needed for
> conversion to a stream (cout, lexical_cast to string, etc..).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (THRIFT-4060) Thrift printTo ostream overload mechanism breaks down when types are nested
[
https://issues.apache.org/jira/browse/THRIFT-4060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King, III resolved THRIFT-4060.
Resolution: Fixed
Fix Version/s: 0.11.0
> Thrift printTo ostream overload mechanism breaks down when types are nested
> ---
>
> Key: THRIFT-4060
> URL: https://issues.apache.org/jira/browse/THRIFT-4060
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Compiler
>Affects Versions: 0.9.3, 0.10.0
> Environment: Ubuntu 14.04 LTS
>Reporter: James E. King, III
>Assignee: James E. King, III
> Fix For: 0.11.0
>
>
> I'm in the middle of converting a project that provides some ostream
> operators (for logging purposes) for a number of thrift structures. The
> project was using 0.8.0 and in 0.9.3 some ostream operator overloads were
> added with THRIFT-3336. The solution that was provided here runs into
> complications if a thrift structure is contained within another one. Take
> this simple example:
> h4. Thrift
> {noformat}
> namespace cpp example.detail
> struct Lower {
>1: binary lowerBinary
> }
> struct Higher {
> 1: set lowers
> }
> {noformat}
> h4. C++
> {noformat}
> namespace example {
> class MyLower : public detail::Lower
> {
> virtual void printTo(std::ostream& os) const override;
> }
> class MyHigher : public detail::Higher
> {
> virtual void printTo(std::ostream& os) const override
> {
> os << lowers;
> // here's the problem, lowers is a set when it
> serializes in,
> // not a set, so I cannot override it...
> }
> }
> }
> {noformat}
> I'm considering adding an annotation to the thrift IDL that the compiler will
> recognize that allows someone to say, "I am going to provide my own
> operator<< for this structure, don't generate one". This would replace the
> printTo mechanism that was added in THRIFT-3336.
> Here is an example:
> {noformat}
> namespace cpp example.detail
> struct MyLower {
>1: binary lowerBinary
> } (cpp.customostream)
> struct MyHigher {
> 1: set lowers
> }
> {noformat}
> The annotation {{cpp.customostream}} (or the compiler option {{--gen
> cpp:no_ostream_operators}} for global effect) tells the compiler to emit only
> the declaration of the {{operator <<}} but does not emit a definition
> (implementation). It would be up to the implementation building against the
> generated code to provide an operator << if such an operator is needed for
> conversion to a stream (cout, lexical_cast to string, etc..).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] thrift pull request #1172: THRIFT-4060 add better support in the cpp generat...
Github user asfgit closed the pull request at: https://github.com/apache/thrift/pull/1172 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (THRIFT-4066) Perl client, C++ Server in cross test with SSL fails, tlsv1 alert unknown ca
[
https://issues.apache.org/jira/browse/THRIFT-4066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15864483#comment-15864483
]
ASF GitHub Bot commented on THRIFT-4066:
GitHub user jeking3 opened a pull request:
https://github.com/apache/thrift/pull/1189
THRIFT-4066 fix perl client in cross test not sending expected certificate
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/jeking3/thrift THRIFT-4066
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/thrift/pull/1189.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #1189
> Perl client, C++ Server in cross test with SSL fails, tlsv1 alert unknown ca
>
>
> Key: THRIFT-4066
> URL: https://issues.apache.org/jira/browse/THRIFT-4066
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library, Perl - Library, Test Suite
>Affects Versions: 0.10.0
> Environment: Ubuntu 14.04 (gcc 4.6.4) Perl 5.18
>Reporter: James E. King, III
>Assignee: James E. King, III
>
> I re-enabled the two cpp-perl SSL based tests in make cross and they failed:
> cpp-perlbinary framed-ip-sslfailure(255)
> cpp-perlbinary buffered-ip-ssl failure(255)
> The cpp server complained that "tlsv1 alert unknown ca".
> {noformat}
> Thu Feb 02 14:07:33 2017
> Executing: /home/jking/thrift/github/thrift/test/cpp/TestServer
> --protocol=binary --transport=buffered --ssl --port=41785
> Directory: /home/jking/thrift/github/thrift/test/cpp
> config:delay: 5
> config:timeout: 5
> ==
> Starting "simple" server (buffered/binary) listen on: 41785
> Thrift: Thu Feb 2 14:07:33 2017 TConnectedClient died: SSL_accept: error
> code: 0
> Thrift: Thu Feb 2 14:07:33 2017 TConnectedClient died: SSL_accept: tlsv1
> alert unknown ca
> Thrift: Thu Feb 2 14:07:33 2017 TConnectedClient died: SSL_accept: tlsv1
> alert unknown ca
> Thrift: Thu Feb 2 14:07:34 2017 TConnectedClient died: SSL_accept: tlsv1
> alert unknown ca
> Thrift: Thu Feb 2 14:07:34 2017 TConnectedClient died: SSL_accept: tlsv1
> alert unknown ca
> Thrift: Thu Feb 2 14:07:34 2017 TConnectedClient died: SSL_accept: tlsv1
> alert unknown ca
> Thrift: Thu Feb 2 14:07:34 2017 TConnectedClient died: SSL_accept: tlsv1
> alert unknown ca
> Thrift: Thu Feb 2 14:07:35 2017 TConnectedClient died: SSL_accept: tlsv1
> alert unknown ca
> Thrift: Thu Feb 2 14:07:35 2017 TConnectedClient died: SSL_accept: tlsv1
> alert unknown ca
> Server process is successfully killed.
> ==
> Process is killed.
> Test execution took 2.2 seconds.
> Thu Feb 02 14:07:35 2017
> {noformat}
> The perl client simply said it could not connect:
> {noformat}
> Thu Feb 02 14:07:35 2017
> Executing: perl -Igen-perl/ -I../../lib/perl/lib/ TestClient.pl
> --cert=../keys/client.pem --protocol=binary --transport=buffered --ssl
> --port=41785
> Directory: /home/jking/thrift/github/thrift/test/perl
> config:delay: 5
> config:timeout: 5
> ==
> $VAR1 = bless( {
> 'message' => 'Thrift::SSLSocket: Could not connect to
> localhost:41785 ()',
> 'code' => 0
>}, 'Thrift::TException' );
> ==
> Return code: 255
> Test execution took 0.1 seconds.
> Thu Feb 02 14:07:35 2017
> {noformat}
> Given both tests should be using the same certificate files, this is quite
> odd.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] thrift pull request #1189: THRIFT-4066 fix perl client in cross test not sen...
GitHub user jeking3 opened a pull request: https://github.com/apache/thrift/pull/1189 THRIFT-4066 fix perl client in cross test not sending expected certificate You can merge this pull request into a Git repository by running: $ git pull https://github.com/jeking3/thrift THRIFT-4066 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/thrift/pull/1189.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1189 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (THRIFT-1805) Thrift should not swallow ALL exceptions
[ https://issues.apache.org/jira/browse/THRIFT-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15864471#comment-15864471 ] ASF GitHub Bot commented on THRIFT-1805: Github user ctubbsii commented on a diff in the pull request: https://github.com/apache/thrift/pull/1186#discussion_r100901172 --- Diff: compiler/cpp/src/thrift/generate/t_java_generator.cc --- @@ -5265,6 +5274,9 @@ THRIFT_REGISTER_GENERATOR( "android_legacy: Do not use java.io.IOException(throwable) (available for Android 2.3 and " "above).\n" "option_type: Wrap optional fields in an Option type.\n" +"handle_runtime_exceptions:\n" +" Generated services will handle RuntimeException as " --- End diff -- I think it'd be hard to properly explain the TTransportException the client will experience otherwise, in a short usage text. > Thrift should not swallow ALL exceptions > > > Key: THRIFT-1805 > URL: https://issues.apache.org/jira/browse/THRIFT-1805 > Project: Thrift > Issue Type: Bug > Components: Java - Compiler, Java - Library >Affects Versions: 0.9 >Reporter: Diwaker Gupta >Assignee: Diwaker Gupta > Attachments: THRIFT-1805.patch > > > In Thrift 0.8.0, Thrift generated Java code did not swallow application > exceptions. As a result of THRIFT-1658, this behavior changed in 0.9.0 and > now the generated code swallows ALL application exceptions (via > ProcessFunction). Apparently this was the behavior in Thrift 0.6.0 and while > I see the rationale, it is breaking our applications. > Our code relies on the fact that exceptions can propagate outside of Thrift > for certain things (e.g., to aggressively drop connections for clients that > send invalid/malformed requests). ProcessFunction makes it near impossible to > do this -- not only does it swallow the exception, it also loses all > information about the original exception and just writes out a generic > TApplicationException. > IMO ProcessFunction should only catch TException. If the application code > wants to use other exceptions for some reason (in particular, Errors and > RuntimeExceptions), Thrift shouldn't prevent that. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] thrift pull request #1186: THRIFT-1805 Provide option for handling RTEs
Github user ctubbsii commented on a diff in the pull request: https://github.com/apache/thrift/pull/1186#discussion_r100901172 --- Diff: compiler/cpp/src/thrift/generate/t_java_generator.cc --- @@ -5265,6 +5274,9 @@ THRIFT_REGISTER_GENERATOR( "android_legacy: Do not use java.io.IOException(throwable) (available for Android 2.3 and " "above).\n" "option_type: Wrap optional fields in an Option type.\n" +"handle_runtime_exceptions:\n" +" Generated services will handle RuntimeException as " --- End diff -- I think it'd be hard to properly explain the TTransportException the client will experience otherwise, in a short usage text. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] thrift pull request #1185: Thrift 3369 - Third try to merge SSL c_glib
Github user asfgit closed the pull request at: https://github.com/apache/thrift/pull/1185 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (THRIFT-4066) Perl client, C++ Server in cross test with SSL fails, tlsv1 alert unknown ca
[
https://issues.apache.org/jira/browse/THRIFT-4066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15864387#comment-15864387
]
James E. King, III commented on THRIFT-4066:
Root cause on this was that the perl SSLSocket was not getting all the options
like certificate, ca, etc... because the base socket class did not handle when
options are passed in as a hash, and the TestClient never passed in the option
hash.
> Perl client, C++ Server in cross test with SSL fails, tlsv1 alert unknown ca
>
>
> Key: THRIFT-4066
> URL: https://issues.apache.org/jira/browse/THRIFT-4066
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library, Perl - Library, Test Suite
>Affects Versions: 0.10.0
> Environment: Ubuntu 14.04 (gcc 4.6.4) Perl 5.18
>Reporter: James E. King, III
>Assignee: James E. King, III
>
> I re-enabled the two cpp-perl SSL based tests in make cross and they failed:
> cpp-perlbinary framed-ip-sslfailure(255)
> cpp-perlbinary buffered-ip-ssl failure(255)
> The cpp server complained that "tlsv1 alert unknown ca".
> {noformat}
> Thu Feb 02 14:07:33 2017
> Executing: /home/jking/thrift/github/thrift/test/cpp/TestServer
> --protocol=binary --transport=buffered --ssl --port=41785
> Directory: /home/jking/thrift/github/thrift/test/cpp
> config:delay: 5
> config:timeout: 5
> ==
> Starting "simple" server (buffered/binary) listen on: 41785
> Thrift: Thu Feb 2 14:07:33 2017 TConnectedClient died: SSL_accept: error
> code: 0
> Thrift: Thu Feb 2 14:07:33 2017 TConnectedClient died: SSL_accept: tlsv1
> alert unknown ca
> Thrift: Thu Feb 2 14:07:33 2017 TConnectedClient died: SSL_accept: tlsv1
> alert unknown ca
> Thrift: Thu Feb 2 14:07:34 2017 TConnectedClient died: SSL_accept: tlsv1
> alert unknown ca
> Thrift: Thu Feb 2 14:07:34 2017 TConnectedClient died: SSL_accept: tlsv1
> alert unknown ca
> Thrift: Thu Feb 2 14:07:34 2017 TConnectedClient died: SSL_accept: tlsv1
> alert unknown ca
> Thrift: Thu Feb 2 14:07:34 2017 TConnectedClient died: SSL_accept: tlsv1
> alert unknown ca
> Thrift: Thu Feb 2 14:07:35 2017 TConnectedClient died: SSL_accept: tlsv1
> alert unknown ca
> Thrift: Thu Feb 2 14:07:35 2017 TConnectedClient died: SSL_accept: tlsv1
> alert unknown ca
> Server process is successfully killed.
> ==
> Process is killed.
> Test execution took 2.2 seconds.
> Thu Feb 02 14:07:35 2017
> {noformat}
> The perl client simply said it could not connect:
> {noformat}
> Thu Feb 02 14:07:35 2017
> Executing: perl -Igen-perl/ -I../../lib/perl/lib/ TestClient.pl
> --cert=../keys/client.pem --protocol=binary --transport=buffered --ssl
> --port=41785
> Directory: /home/jking/thrift/github/thrift/test/perl
> config:delay: 5
> config:timeout: 5
> ==
> $VAR1 = bless( {
> 'message' => 'Thrift::SSLSocket: Could not connect to
> localhost:41785 ()',
> 'code' => 0
>}, 'Thrift::TException' );
> ==
> Return code: 255
> Test execution took 0.1 seconds.
> Thu Feb 02 14:07:35 2017
> {noformat}
> Given both tests should be using the same certificate files, this is quite
> odd.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (THRIFT-1805) Thrift should not swallow ALL exceptions
[ https://issues.apache.org/jira/browse/THRIFT-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15864270#comment-15864270 ] ASF GitHub Bot commented on THRIFT-1805: Github user keith-turner commented on a diff in the pull request: https://github.com/apache/thrift/pull/1186#discussion_r100875982 --- Diff: compiler/cpp/src/thrift/generate/t_java_generator.cc --- @@ -5265,6 +5274,9 @@ THRIFT_REGISTER_GENERATOR( "android_legacy: Do not use java.io.IOException(throwable) (available for Android 2.3 and " "above).\n" "option_type: Wrap optional fields in an Option type.\n" +"handle_runtime_exceptions:\n" +" Generated services will handle RuntimeException as " --- End diff -- I like that. I was also trying to document what the default behavior is. When someone is trying to make decision about enabling the option, its nice to know what not enabling it means. > Thrift should not swallow ALL exceptions > > > Key: THRIFT-1805 > URL: https://issues.apache.org/jira/browse/THRIFT-1805 > Project: Thrift > Issue Type: Bug > Components: Java - Compiler, Java - Library >Affects Versions: 0.9 >Reporter: Diwaker Gupta >Assignee: Diwaker Gupta > Attachments: THRIFT-1805.patch > > > In Thrift 0.8.0, Thrift generated Java code did not swallow application > exceptions. As a result of THRIFT-1658, this behavior changed in 0.9.0 and > now the generated code swallows ALL application exceptions (via > ProcessFunction). Apparently this was the behavior in Thrift 0.6.0 and while > I see the rationale, it is breaking our applications. > Our code relies on the fact that exceptions can propagate outside of Thrift > for certain things (e.g., to aggressively drop connections for clients that > send invalid/malformed requests). ProcessFunction makes it near impossible to > do this -- not only does it swallow the exception, it also loses all > information about the original exception and just writes out a generic > TApplicationException. > IMO ProcessFunction should only catch TException. If the application code > wants to use other exceptions for some reason (in particular, Errors and > RuntimeExceptions), Thrift shouldn't prevent that. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] thrift pull request #1186: THRIFT-1805 Provide option for handling RTEs
Github user keith-turner commented on a diff in the pull request: https://github.com/apache/thrift/pull/1186#discussion_r100875982 --- Diff: compiler/cpp/src/thrift/generate/t_java_generator.cc --- @@ -5265,6 +5274,9 @@ THRIFT_REGISTER_GENERATOR( "android_legacy: Do not use java.io.IOException(throwable) (available for Android 2.3 and " "above).\n" "option_type: Wrap optional fields in an Option type.\n" +"handle_runtime_exceptions:\n" +" Generated services will handle RuntimeException as " --- End diff -- I like that. I was also trying to document what the default behavior is. When someone is trying to make decision about enabling the option, its nice to know what not enabling it means. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (THRIFT-1805) Thrift should not swallow ALL exceptions
[ https://issues.apache.org/jira/browse/THRIFT-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15864250#comment-15864250 ] ASF GitHub Bot commented on THRIFT-1805: Github user ctubbsii commented on a diff in the pull request: https://github.com/apache/thrift/pull/1186#discussion_r100873930 --- Diff: compiler/cpp/src/thrift/generate/t_java_generator.cc --- @@ -5265,6 +5274,9 @@ THRIFT_REGISTER_GENERATOR( "android_legacy: Do not use java.io.IOException(throwable) (available for Android 2.3 and " "above).\n" "option_type: Wrap optional fields in an Option type.\n" +"handle_runtime_exceptions:\n" +" Generated services will handle RuntimeException as " --- End diff -- The output of `thrift --help` is already quite long, so I don't think an extra line or two is going to matter. What probably matters more is brevity and formatting for readability. How about simply: `Send TApplicationException to clients when RuntimeException occurs on the server` ? > Thrift should not swallow ALL exceptions > > > Key: THRIFT-1805 > URL: https://issues.apache.org/jira/browse/THRIFT-1805 > Project: Thrift > Issue Type: Bug > Components: Java - Compiler, Java - Library >Affects Versions: 0.9 >Reporter: Diwaker Gupta >Assignee: Diwaker Gupta > Attachments: THRIFT-1805.patch > > > In Thrift 0.8.0, Thrift generated Java code did not swallow application > exceptions. As a result of THRIFT-1658, this behavior changed in 0.9.0 and > now the generated code swallows ALL application exceptions (via > ProcessFunction). Apparently this was the behavior in Thrift 0.6.0 and while > I see the rationale, it is breaking our applications. > Our code relies on the fact that exceptions can propagate outside of Thrift > for certain things (e.g., to aggressively drop connections for clients that > send invalid/malformed requests). ProcessFunction makes it near impossible to > do this -- not only does it swallow the exception, it also loses all > information about the original exception and just writes out a generic > TApplicationException. > IMO ProcessFunction should only catch TException. If the application code > wants to use other exceptions for some reason (in particular, Errors and > RuntimeExceptions), Thrift shouldn't prevent that. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] thrift pull request #1186: THRIFT-1805 Provide option for handling RTEs
Github user ctubbsii commented on a diff in the pull request: https://github.com/apache/thrift/pull/1186#discussion_r100873930 --- Diff: compiler/cpp/src/thrift/generate/t_java_generator.cc --- @@ -5265,6 +5274,9 @@ THRIFT_REGISTER_GENERATOR( "android_legacy: Do not use java.io.IOException(throwable) (available for Android 2.3 and " "above).\n" "option_type: Wrap optional fields in an Option type.\n" +"handle_runtime_exceptions:\n" +" Generated services will handle RuntimeException as " --- End diff -- The output of `thrift --help` is already quite long, so I don't think an extra line or two is going to matter. What probably matters more is brevity and formatting for readability. How about simply: `Send TApplicationException to clients when RuntimeException occurs on the server` ? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (THRIFT-1805) Thrift should not swallow ALL exceptions
[ https://issues.apache.org/jira/browse/THRIFT-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15864163#comment-15864163 ] ASF GitHub Bot commented on THRIFT-1805: Github user keith-turner commented on a diff in the pull request: https://github.com/apache/thrift/pull/1186#discussion_r100861533 --- Diff: compiler/cpp/src/thrift/generate/t_java_generator.cc --- @@ -5265,6 +5274,9 @@ THRIFT_REGISTER_GENERATOR( "android_legacy: Do not use java.io.IOException(throwable) (available for Android 2.3 and " "above).\n" "option_type: Wrap optional fields in an Option type.\n" +"handle_runtime_exceptions:\n" +" Generated services will handle RuntimeException as " --- End diff -- I think the following documentation gives users a little more insight into what this option does. Is there a length limit? I was trying to make the following short. ``` Adjust how server handles RuntimeException (RE). Default is to close connection on RE. This enables sending TApplicationException on RE. ``` > Thrift should not swallow ALL exceptions > > > Key: THRIFT-1805 > URL: https://issues.apache.org/jira/browse/THRIFT-1805 > Project: Thrift > Issue Type: Bug > Components: Java - Compiler, Java - Library >Affects Versions: 0.9 >Reporter: Diwaker Gupta >Assignee: Diwaker Gupta > Attachments: THRIFT-1805.patch > > > In Thrift 0.8.0, Thrift generated Java code did not swallow application > exceptions. As a result of THRIFT-1658, this behavior changed in 0.9.0 and > now the generated code swallows ALL application exceptions (via > ProcessFunction). Apparently this was the behavior in Thrift 0.6.0 and while > I see the rationale, it is breaking our applications. > Our code relies on the fact that exceptions can propagate outside of Thrift > for certain things (e.g., to aggressively drop connections for clients that > send invalid/malformed requests). ProcessFunction makes it near impossible to > do this -- not only does it swallow the exception, it also loses all > information about the original exception and just writes out a generic > TApplicationException. > IMO ProcessFunction should only catch TException. If the application code > wants to use other exceptions for some reason (in particular, Errors and > RuntimeExceptions), Thrift shouldn't prevent that. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] thrift pull request #1186: THRIFT-1805 Provide option for handling RTEs
Github user keith-turner commented on a diff in the pull request: https://github.com/apache/thrift/pull/1186#discussion_r100861533 --- Diff: compiler/cpp/src/thrift/generate/t_java_generator.cc --- @@ -5265,6 +5274,9 @@ THRIFT_REGISTER_GENERATOR( "android_legacy: Do not use java.io.IOException(throwable) (available for Android 2.3 and " "above).\n" "option_type: Wrap optional fields in an Option type.\n" +"handle_runtime_exceptions:\n" +" Generated services will handle RuntimeException as " --- End diff -- I think the following documentation gives users a little more insight into what this option does. Is there a length limit? I was trying to make the following short. ``` Adjust how server handles RuntimeException (RE). Default is to close connection on RE. This enables sending TApplicationException on RE. ``` --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] thrift pull request #1188: Check for joinable before attempting join in thre...
GitHub user cgrebeld opened a pull request: https://github.com/apache/thrift/pull/1188 Check for joinable before attempting join in thread destructors A spurious exception is thrown when shutting down TThreadedServer via drainDeadClients because threads are joined before being destroyed. You can merge this pull request into a Git repository by running: $ git pull https://github.com/cgrebeld/thrift master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/thrift/pull/1188.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1188 commit 513cbfb1b13ffa2f6aa8f87532bebdf86001a218 Author: Chris Grebeldinger Date: 2017-02-13T18:26:13Z Check for joinable before attempting join in thread destructors --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] thrift issue #1185: Thrift 3369 - Third try to merge SSL c_glib
Github user gadLinux commented on the issue: https://github.com/apache/thrift/pull/1185 I cross my fingers so it passes the tests. I want to continue coding but I don't want to do it until we have this issue merged. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (THRIFT-4084) Improve SSL security in thrift by adding a make cross client that checks to make sure SSLv3 protocol cannot be negotiated
[ https://issues.apache.org/jira/browse/THRIFT-4084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15863726#comment-15863726 ] ASF GitHub Bot commented on THRIFT-4084: Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1185 My guess is that the python tests are no longer correct, or the method of making python use SSLv23 in the code we merged is wrong. What I would suggest is backing out the last patch db9ac77f1e9c01ae57a9c6df48cb8670e9045ebb which changed the python stuff. I have cherry picked that into THRIFT-4084 which I am working on so you can drop it. I will send you another PR shortly which eliminates this non-c_glib stuff from your effort and passes both "make check" and "make cross" locally. > Improve SSL security in thrift by adding a make cross client that checks to > make sure SSLv3 protocol cannot be negotiated > - > > Key: THRIFT-4084 > URL: https://issues.apache.org/jira/browse/THRIFT-4084 > Project: Thrift > Issue Type: Improvement > Components: Test Suite >Affects Versions: 0.10.0 > Environment: Ubuntu Dockerfile >Reporter: James E. King, III >Assignee: James E. King, III > Labels: cross-validation, security, ssl, tls > > Following code review discussions in THRIFT-3369, and seeing THRIFT-3165 in > the backlog, I want to add a make cross "language" which isn't a language at > all, but a test that checks to see if it is possible to negotiate at various > SSL/TLS protocol versions. This would be a client-only test, likely just a > bash script that leverages the openssl client and command line options to > connect to a test server and see if it handshakes and negotiates protocol > successfully. > Without THRIFT-3165 implemented, it will ensure: > * Can handshake using the universal SSLv23 context, however cannot negotiate > SSLv3 > * Can negotiate TLSv1.0, TLSv1.1, and TLSv1.2 > With THRIFT-3165 it needs to change to ensure: > * Can handshake using TLSv1.2 but not any other version -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] thrift issue #1185: Thrift 3369 - Third try to merge SSL c_glib
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1185 My guess is that the python tests are no longer correct, or the method of making python use SSLv23 in the code we merged is wrong. What I would suggest is backing out the last patch db9ac77f1e9c01ae57a9c6df48cb8670e9045ebb which changed the python stuff. I have cherry picked that into THRIFT-4084 which I am working on so you can drop it. I will send you another PR shortly which eliminates this non-c_glib stuff from your effort and passes both "make check" and "make cross" locally. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (THRIFT-4060) Thrift printTo ostream overload mechanism breaks down when types are nested
[
https://issues.apache.org/jira/browse/THRIFT-4060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15863569#comment-15863569
]
Konrad Grochowski commented on THRIFT-4060:
---
IMHO: ifdef is still better because it allows implementers to make decision
about `ostream<<` later in development process (for example: when thrift files
are somehow shared and can't be easily modified etc.)
I also recall some very old discussion about keeping thrift compiler
options/switches to minimum.
But that's just opinion - don't treat it "blocking" :)
> Thrift printTo ostream overload mechanism breaks down when types are nested
> ---
>
> Key: THRIFT-4060
> URL: https://issues.apache.org/jira/browse/THRIFT-4060
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Compiler
>Affects Versions: 0.9.3, 0.10.0
> Environment: Ubuntu 14.04 LTS
>Reporter: James E. King, III
>Assignee: James E. King, III
>
> I'm in the middle of converting a project that provides some ostream
> operators (for logging purposes) for a number of thrift structures. The
> project was using 0.8.0 and in 0.9.3 some ostream operator overloads were
> added with THRIFT-3336. The solution that was provided here runs into
> complications if a thrift structure is contained within another one. Take
> this simple example:
> h4. Thrift
> {noformat}
> namespace cpp example.detail
> struct Lower {
>1: binary lowerBinary
> }
> struct Higher {
> 1: set lowers
> }
> {noformat}
> h4. C++
> {noformat}
> namespace example {
> class MyLower : public detail::Lower
> {
> virtual void printTo(std::ostream& os) const override;
> }
> class MyHigher : public detail::Higher
> {
> virtual void printTo(std::ostream& os) const override
> {
> os << lowers;
> // here's the problem, lowers is a set when it
> serializes in,
> // not a set, so I cannot override it...
> }
> }
> }
> {noformat}
> I'm considering adding an annotation to the thrift IDL that the compiler will
> recognize that allows someone to say, "I am going to provide my own
> operator<< for this structure, don't generate one". This would replace the
> printTo mechanism that was added in THRIFT-3336.
> Here is an example:
> {noformat}
> namespace cpp example.detail
> struct MyLower {
>1: binary lowerBinary
> } (cpp.customostream)
> struct MyHigher {
> 1: set lowers
> }
> {noformat}
> The annotation {{cpp.customostream}} (or the compiler option {{--gen
> cpp:no_ostream_operators}} for global effect) tells the compiler to emit only
> the declaration of the {{operator <<}} but does not emit a definition
> (implementation). It would be up to the implementation building against the
> generated code to provide an operator << if such an operator is needed for
> conversion to a stream (cout, lexical_cast to string, etc..).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (THRIFT-4086) Java compiler generates different meta data depending on order of structures in file
[
https://issues.apache.org/jira/browse/THRIFT-4086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Batylin updated THRIFT-4086:
--
Description:
When compiling th following thrift code:
{code}
struct Customer {
1: required i32 customer_id,
2: required list orders
}
struct Order {
1: required i32 order_id,
}
{code}
compiler generates meta data for {{orders}} field as {{FieldValueMetaData}}:
{code}
tmpMap.put(_Fields.ORDERS, new
org.apache.thrift.meta_data.FieldMetaData("orders",
org.apache.thrift.TFieldRequirementType.REQUIRED,
new
org.apache.thrift.meta_data.ListMetaData(org.apache.thrift.protocol.TType.LIST,
new
org.apache.thrift.meta_data.FieldValueMetaData(org.apache.thrift.protocol.TType.STRUCT
, "Order";
{code}
If structs order is reversed:
{code}
struct Order {
1: required i32 order_id,
}
struct Customer {
1: required i32 customer_id,
2: required list orders
}
{code}
compiler generates meta data for {{orders}} field as {{StructMetaData}}:
{code}
tmpMap.put(_Fields.ORDERS, new
org.apache.thrift.meta_data.FieldMetaData("orders",
org.apache.thrift.TFieldRequirementType.REQUIRED,
new
org.apache.thrift.meta_data.ListMetaData(org.apache.thrift.protocol.TType.LIST,
new
org.apache.thrift.meta_data.StructMetaData(org.apache.thrift.protocol.TType.STRUCT,
Order.class;
{code}
was:
When compiling th following thrift code:
{code}
struct Customer {
1: required i32 customer_id,
2: required list orders
}
struct Order {
1: required i32 order_id,
}
{code}
compiler generates meta data for {{orders}} field as {{FieldValueMetaData}}:
{quote}
tmpMap.put(_Fields.ORDERS, new
org.apache.thrift.meta_data.FieldMetaData("orders",
org.apache.thrift.TFieldRequirementType.REQUIRED,
new
org.apache.thrift.meta_data.ListMetaData(org.apache.thrift.protocol.TType.LIST,
new
org.apache.thrift.meta_data.FieldValueMetaData(org.apache.thrift.protocol.TType.STRUCT
, "Order";
{quote}
If structs order is reversed:
{quote}
struct Order {
1: required i32 order_id,
}
struct Customer {
1: required i32 customer_id,
2: required list orders
}
{quote}
compiler generates meta data for {{orders}} field as {{StructMetaData}}:
{quote}
tmpMap.put(_Fields.ORDERS, new
org.apache.thrift.meta_data.FieldMetaData("orders",
org.apache.thrift.TFieldRequirementType.REQUIRED,
new
org.apache.thrift.meta_data.ListMetaData(org.apache.thrift.protocol.TType.LIST,
new
org.apache.thrift.meta_data.StructMetaData(org.apache.thrift.protocol.TType.STRUCT,
Order.class;
{quote}
> Java compiler generates different meta data depending on order of structures
> in file
>
>
> Key: THRIFT-4086
> URL: https://issues.apache.org/jira/browse/THRIFT-4086
> Project: Thrift
> Issue Type: Bug
> Components: Java - Compiler
>Affects Versions: 0.9.3, 0.10.0
>Reporter: Anton Batylin
>
> When compiling th following thrift code:
> {code}
> struct Customer {
> 1: required i32 customer_id,
> 2: required list orders
> }
> struct Order {
> 1: required i32 order_id,
> }
> {code}
> compiler generates meta data for {{orders}} field as {{FieldValueMetaData}}:
> {code}
> tmpMap.put(_Fields.ORDERS, new
> org.apache.thrift.meta_data.FieldMetaData("orders",
> org.apache.thrift.TFieldRequirementType.REQUIRED,
> new
> org.apache.thrift.meta_data.ListMetaData(org.apache.thrift.protocol.TType.LIST,
>
> new
> org.apache.thrift.meta_data.FieldValueMetaData(org.apache.thrift.protocol.TType.STRUCT
> , "Order";
> {code}
> If structs order is reversed:
> {code}
> struct Order {
> 1: required i32 order_id,
> }
> struct Customer {
> 1: required i32 customer_id,
> 2: required list orders
> }
> {code}
> compiler generates meta data for {{orders}} field as {{StructMetaData}}:
> {code}
> tmpMap.put(_Fields.ORDERS, new
> org.apache.thrift.meta_data.FieldMetaData("orders",
> org.apache.thrift.TFieldRequirementType.REQUIRED,
> new
> org.apache.thrift.meta_data.ListMetaData(org.apache.thrift.protocol.TType.LIST,
>
> new
> org.apache.thrift.meta_data.StructMetaData(org.apache.thrift.protocol.TType.STRUCT,
> Order.class;
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (THRIFT-4061) The Thrift IDL does not include information about annotations
[ https://issues.apache.org/jira/browse/THRIFT-4061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III reassigned THRIFT-4061: -- Assignee: (was: James E. King, III) > The Thrift IDL does not include information about annotations > - > > Key: THRIFT-4061 > URL: https://issues.apache.org/jira/browse/THRIFT-4061 > Project: Thrift > Issue Type: Improvement > Components: Website >Affects Versions: 0.10.0 >Reporter: James E. King, III >Priority: Minor > > I'm looking over the ThriftTest.thrift and I found an annotation called > "py.immutable". I looked it up and it is recognized in the python generator > as an annotation. I searched for the word "annotation" in the published > Thrift IDL on the web site and I did not see anything. I do not see anything > in the published IDL that would explain how to annotate a structure. > http://thrift.apache.org/docs/idl -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (THRIFT-4037) [CMake] Use a single build system for thrift to make development easier
[ https://issues.apache.org/jira/browse/THRIFT-4037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15863455#comment-15863455 ] Gonzalo Aguilar commented on THRIFT-4037: - Looking at the build time figures. Ninja can be a great addition to the CMake build. It seems it can generate result files so it's okay. > [CMake] Use a single build system for thrift to make development easier > --- > > Key: THRIFT-4037 > URL: https://issues.apache.org/jira/browse/THRIFT-4037 > Project: Thrift > Issue Type: Epic > Components: Build Process >Affects Versions: 0.10.0 > Environment: All >Reporter: James E. King, III >Assignee: James E. King, III >Priority: Critical > > h1. Background > The thrift project currently carries two build systems. The original build > system is based on autoconf and is used to build a complete deliverable > including extensive cross-language testing. > The other build system was introduced a few years ago, with roots tracing > back to THRIFT-797. CMake allows thrift to build natively on multiple > platforms - unix and windows. Autoconf is no longer under active development > with the last release in 2012, and it does not allow for native windows > builds using native tools that are used by a majority of consumers. > Maintaining two build systems for a project incurs a lot of overhead. Every > change that touches the build system needs to be done twice, in two > completely different ways. We need twice as many CI jobs to verify that all > of the builds are working, whereas with a single cmake build environment we > could likely use a single CI build job per platform that does everything > using the docker image on linux and appveyor on windows. > h1. Proposal > We should officially deprecate autoconf in favor of cmake, and continue (more > aggressively) the effort to make the cmake build environment as functional as > the autoconf build environment. During this transition, folks will be > required to make changes to both build systems (which are proven out mostly > through the Travis CI build jobs; only CMake is used on AppVeyor). > h1. Acceptance Criteria > # All existing platforms, targets, and tests are converted to use cmake > ## Including cross-compilation > # All CI builds are converted to use cmake > # autoconf build environment is removed -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (THRIFT-4086) Java compiler generates different meta data depending on order of structures in file
[
https://issues.apache.org/jira/browse/THRIFT-4086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Batylin updated THRIFT-4086:
--
Description:
When compiling th following thrift code:
{code}
struct Customer {
1: required i32 customer_id,
2: required list orders
}
struct Order {
1: required i32 order_id,
}
{code}
compiler generates meta data for {{orders}} field as {{FieldValueMetaData}}:
{quote}
tmpMap.put(_Fields.ORDERS, new
org.apache.thrift.meta_data.FieldMetaData("orders",
org.apache.thrift.TFieldRequirementType.REQUIRED,
new
org.apache.thrift.meta_data.ListMetaData(org.apache.thrift.protocol.TType.LIST,
new
org.apache.thrift.meta_data.FieldValueMetaData(org.apache.thrift.protocol.TType.STRUCT
, "Order";
{quote}
If structs order is reversed:
{quote}
struct Order {
1: required i32 order_id,
}
struct Customer {
1: required i32 customer_id,
2: required list orders
}
{quote}
compiler generates meta data for {{orders}} field as {{StructMetaData}}:
{quote}
tmpMap.put(_Fields.ORDERS, new
org.apache.thrift.meta_data.FieldMetaData("orders",
org.apache.thrift.TFieldRequirementType.REQUIRED,
new
org.apache.thrift.meta_data.ListMetaData(org.apache.thrift.protocol.TType.LIST,
new
org.apache.thrift.meta_data.StructMetaData(org.apache.thrift.protocol.TType.STRUCT,
Order.class;
{quote}
was:
When compiling th following thrift code:
{quote}
struct Customer {
1: required i32 customer_id,
2: required list orders
}
struct Order {
1: required i32 order_id,
}
{quote}
compiler generates meta data for {{orders}} field as {{FieldValueMetaData}}:
{quote}
tmpMap.put(_Fields.ORDERS, new
org.apache.thrift.meta_data.FieldMetaData("orders",
org.apache.thrift.TFieldRequirementType.REQUIRED,
new
org.apache.thrift.meta_data.ListMetaData(org.apache.thrift.protocol.TType.LIST,
new
org.apache.thrift.meta_data.FieldValueMetaData(org.apache.thrift.protocol.TType.STRUCT
, "Order";
{quote}
If structs order is reversed:
{quote}
struct Order {
1: required i32 order_id,
}
struct Customer {
1: required i32 customer_id,
2: required list orders
}
{quote}
compiler generates meta data for {{orders}} field as {{StructMetaData}}:
{quote}
tmpMap.put(_Fields.ORDERS, new
org.apache.thrift.meta_data.FieldMetaData("orders",
org.apache.thrift.TFieldRequirementType.REQUIRED,
new
org.apache.thrift.meta_data.ListMetaData(org.apache.thrift.protocol.TType.LIST,
new
org.apache.thrift.meta_data.StructMetaData(org.apache.thrift.protocol.TType.STRUCT,
Order.class;
{quote}
> Java compiler generates different meta data depending on order of structures
> in file
>
>
> Key: THRIFT-4086
> URL: https://issues.apache.org/jira/browse/THRIFT-4086
> Project: Thrift
> Issue Type: Bug
> Components: Java - Compiler
>Affects Versions: 0.9.3, 0.10.0
>Reporter: Anton Batylin
>
> When compiling th following thrift code:
> {code}
> struct Customer {
> 1: required i32 customer_id,
> 2: required list orders
> }
> struct Order {
> 1: required i32 order_id,
> }
> {code}
> compiler generates meta data for {{orders}} field as {{FieldValueMetaData}}:
> {quote}
> tmpMap.put(_Fields.ORDERS, new
> org.apache.thrift.meta_data.FieldMetaData("orders",
> org.apache.thrift.TFieldRequirementType.REQUIRED,
> new
> org.apache.thrift.meta_data.ListMetaData(org.apache.thrift.protocol.TType.LIST,
>
> new
> org.apache.thrift.meta_data.FieldValueMetaData(org.apache.thrift.protocol.TType.STRUCT
> , "Order";
> {quote}
> If structs order is reversed:
> {quote}
> struct Order {
> 1: required i32 order_id,
> }
> struct Customer {
> 1: required i32 customer_id,
> 2: required list orders
> }
> {quote}
> compiler generates meta data for {{orders}} field as {{StructMetaData}}:
> {quote}
> tmpMap.put(_Fields.ORDERS, new
> org.apache.thrift.meta_data.FieldMetaData("orders",
> org.apache.thrift.TFieldRequirementType.REQUIRED,
> new
> org.apache.thrift.meta_data.ListMetaData(org.apache.thrift.protocol.TType.LIST,
>
> new
> org.apache.thrift.meta_data.StructMetaData(org.apache.thrift.protocol.TType.STRUCT,
> Order.class;
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (THRIFT-4011) Sets of Thrift structs generate Go code that can't be serialized to JSON
[
https://issues.apache.org/jira/browse/THRIFT-4011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15863449#comment-15863449
]
ASF GitHub Bot commented on THRIFT-4011:
Github user dcelasun commented on the issue:
https://github.com/apache/thrift/pull/1156
@Jens-G Squashed commits and rebased from master.
> Sets of Thrift structs generate Go code that can't be serialized to JSON
>
>
> Key: THRIFT-4011
> URL: https://issues.apache.org/jira/browse/THRIFT-4011
> Project: Thrift
> Issue Type: Bug
> Components: Go - Compiler
>Reporter: Can Celasun
>
> Consider the following structs:
> {code}
> struct Foo {
> 1: optional string foo
> }
> struct Bar {
> 1: optional set foos
> }
> {code}
> This compiles into the following Go code:
> {code}
> type Bar struct {
> Foos map[*Foo]struct{} `thrift:"foos,1" db:"foos" json:"foos,omitempty"`
> }
> {code}
> Even though the generated code has tags for JSON support, Bar can't be
> serialized to JSON:
> {code}
> json: unsupported type: map[*Foo]struct {}
> {code}
> One solution would be to use slices, not maps, for Thrift sets. Thoughts?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (THRIFT-4086) Java compiler generates different meta data depending on order of structures in file
Anton Batylin created THRIFT-4086:
-
Summary: Java compiler generates different meta data depending on
order of structures in file
Key: THRIFT-4086
URL: https://issues.apache.org/jira/browse/THRIFT-4086
Project: Thrift
Issue Type: Bug
Components: Java - Compiler
Affects Versions: 0.10.0, 0.9.3
Reporter: Anton Batylin
When compiling th following thrift code:
{quote}
struct Customer {
1: required i32 customer_id,
2: required list orders
}
struct Order {
1: required i32 order_id,
}
{quote}
compiler generates meta data for {{orders}} field as {{FieldValueMetaData}}:
{quote}
tmpMap.put(_Fields.ORDERS, new
org.apache.thrift.meta_data.FieldMetaData("orders",
org.apache.thrift.TFieldRequirementType.REQUIRED,
new
org.apache.thrift.meta_data.ListMetaData(org.apache.thrift.protocol.TType.LIST,
new
org.apache.thrift.meta_data.FieldValueMetaData(org.apache.thrift.protocol.TType.STRUCT
, "Order";
{quote}
If structs order is reversed:
{quote}
struct Order {
1: required i32 order_id,
}
struct Customer {
1: required i32 customer_id,
2: required list orders
}
{quote}
compiler generates meta data for {{orders}} field as {{StructMetaData}}:
{quote}
tmpMap.put(_Fields.ORDERS, new
org.apache.thrift.meta_data.FieldMetaData("orders",
org.apache.thrift.TFieldRequirementType.REQUIRED,
new
org.apache.thrift.meta_data.ListMetaData(org.apache.thrift.protocol.TType.LIST,
new
org.apache.thrift.meta_data.StructMetaData(org.apache.thrift.protocol.TType.STRUCT,
Order.class;
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (THRIFT-4086) Java compiler generates different meta data depending on order of structures in file
[
https://issues.apache.org/jira/browse/THRIFT-4086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Batylin updated THRIFT-4086:
--
Description:
When compiling th following thrift code:
{quote}
struct Customer {
1: required i32 customer_id,
2: required list orders
}
struct Order {
1: required i32 order_id,
}
{quote}
compiler generates meta data for {{orders}} field as {{FieldValueMetaData}}:
{quote}
tmpMap.put(_Fields.ORDERS, new
org.apache.thrift.meta_data.FieldMetaData("orders",
org.apache.thrift.TFieldRequirementType.REQUIRED,
new
org.apache.thrift.meta_data.ListMetaData(org.apache.thrift.protocol.TType.LIST,
new
org.apache.thrift.meta_data.FieldValueMetaData(org.apache.thrift.protocol.TType.STRUCT
, "Order";
{quote}
If structs order is reversed:
{quote}
struct Order {
1: required i32 order_id,
}
struct Customer {
1: required i32 customer_id,
2: required list orders
}
{quote}
compiler generates meta data for {{orders}} field as {{StructMetaData}}:
{quote}
tmpMap.put(_Fields.ORDERS, new
org.apache.thrift.meta_data.FieldMetaData("orders",
org.apache.thrift.TFieldRequirementType.REQUIRED,
new
org.apache.thrift.meta_data.ListMetaData(org.apache.thrift.protocol.TType.LIST,
new
org.apache.thrift.meta_data.StructMetaData(org.apache.thrift.protocol.TType.STRUCT,
Order.class;
{quote}
was:
When compiling th following thrift code:
{quote}
struct Customer {{
1: required i32 customer_id,
2: required list orders
}}
struct Order {
1: required i32 order_id,
}
{quote}
compiler generates meta data for {{orders}} field as {{FieldValueMetaData}}:
{quote}
tmpMap.put(_Fields.ORDERS, new
org.apache.thrift.meta_data.FieldMetaData("orders",
org.apache.thrift.TFieldRequirementType.REQUIRED,
new
org.apache.thrift.meta_data.ListMetaData(org.apache.thrift.protocol.TType.LIST,
new
org.apache.thrift.meta_data.FieldValueMetaData(org.apache.thrift.protocol.TType.STRUCT
, "Order";
{quote}
If structs order is reversed:
{quote}
struct Order {
1: required i32 order_id,
}
struct Customer {
1: required i32 customer_id,
2: required list orders
}
{quote}
compiler generates meta data for {{orders}} field as {{StructMetaData}}:
{quote}
tmpMap.put(_Fields.ORDERS, new
org.apache.thrift.meta_data.FieldMetaData("orders",
org.apache.thrift.TFieldRequirementType.REQUIRED,
new
org.apache.thrift.meta_data.ListMetaData(org.apache.thrift.protocol.TType.LIST,
new
org.apache.thrift.meta_data.StructMetaData(org.apache.thrift.protocol.TType.STRUCT,
Order.class;
{quote}
> Java compiler generates different meta data depending on order of structures
> in file
>
>
> Key: THRIFT-4086
> URL: https://issues.apache.org/jira/browse/THRIFT-4086
> Project: Thrift
> Issue Type: Bug
> Components: Java - Compiler
>Affects Versions: 0.9.3, 0.10.0
>Reporter: Anton Batylin
>
> When compiling th following thrift code:
> {quote}
> struct Customer {
> 1: required i32 customer_id,
> 2: required list orders
> }
> struct Order {
> 1: required i32 order_id,
> }
> {quote}
> compiler generates meta data for {{orders}} field as {{FieldValueMetaData}}:
> {quote}
> tmpMap.put(_Fields.ORDERS, new
> org.apache.thrift.meta_data.FieldMetaData("orders",
> org.apache.thrift.TFieldRequirementType.REQUIRED,
> new
> org.apache.thrift.meta_data.ListMetaData(org.apache.thrift.protocol.TType.LIST,
>
> new
> org.apache.thrift.meta_data.FieldValueMetaData(org.apache.thrift.protocol.TType.STRUCT
> , "Order";
> {quote}
> If structs order is reversed:
> {quote}
> struct Order {
> 1: required i32 order_id,
> }
> struct Customer {
> 1: required i32 customer_id,
> 2: required list orders
> }
> {quote}
> compiler generates meta data for {{orders}} field as {{StructMetaData}}:
> {quote}
> tmpMap.put(_Fields.ORDERS, new
> org.apache.thrift.meta_data.FieldMetaData("orders",
> org.apache.thrift.TFieldRequirementType.REQUIRED,
> new
> org.apache.thrift.meta_data.ListMetaData(org.apache.thrift.protocol.TType.LIST,
>
> new
> org.apache.thrift.meta_data.StructMetaData(org.apache.thrift.protocol.TType.STRUCT,
> Order.class;
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (THRIFT-4086) Java compiler generates different meta data depending on order of structures in file
[
https://issues.apache.org/jira/browse/THRIFT-4086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Batylin updated THRIFT-4086:
--
Description:
When compiling th following thrift code:
{quote}
struct Customer {{
1: required i32 customer_id,
2: required list orders
}}
struct Order {
1: required i32 order_id,
}
{quote}
compiler generates meta data for {{orders}} field as {{FieldValueMetaData}}:
{quote}
tmpMap.put(_Fields.ORDERS, new
org.apache.thrift.meta_data.FieldMetaData("orders",
org.apache.thrift.TFieldRequirementType.REQUIRED,
new
org.apache.thrift.meta_data.ListMetaData(org.apache.thrift.protocol.TType.LIST,
new
org.apache.thrift.meta_data.FieldValueMetaData(org.apache.thrift.protocol.TType.STRUCT
, "Order";
{quote}
If structs order is reversed:
{quote}
struct Order {
1: required i32 order_id,
}
struct Customer {
1: required i32 customer_id,
2: required list orders
}
{quote}
compiler generates meta data for {{orders}} field as {{StructMetaData}}:
{quote}
tmpMap.put(_Fields.ORDERS, new
org.apache.thrift.meta_data.FieldMetaData("orders",
org.apache.thrift.TFieldRequirementType.REQUIRED,
new
org.apache.thrift.meta_data.ListMetaData(org.apache.thrift.protocol.TType.LIST,
new
org.apache.thrift.meta_data.StructMetaData(org.apache.thrift.protocol.TType.STRUCT,
Order.class;
{quote}
was:
When compiling th following thrift code:
{quote}
struct Customer {
1: required i32 customer_id,
2: required list orders
}
struct Order {
1: required i32 order_id,
}
{quote}
compiler generates meta data for {{orders}} field as {{FieldValueMetaData}}:
{quote}
tmpMap.put(_Fields.ORDERS, new
org.apache.thrift.meta_data.FieldMetaData("orders",
org.apache.thrift.TFieldRequirementType.REQUIRED,
new
org.apache.thrift.meta_data.ListMetaData(org.apache.thrift.protocol.TType.LIST,
new
org.apache.thrift.meta_data.FieldValueMetaData(org.apache.thrift.protocol.TType.STRUCT
, "Order";
{quote}
If structs order is reversed:
{quote}
struct Order {
1: required i32 order_id,
}
struct Customer {
1: required i32 customer_id,
2: required list orders
}
{quote}
compiler generates meta data for {{orders}} field as {{StructMetaData}}:
{quote}
tmpMap.put(_Fields.ORDERS, new
org.apache.thrift.meta_data.FieldMetaData("orders",
org.apache.thrift.TFieldRequirementType.REQUIRED,
new
org.apache.thrift.meta_data.ListMetaData(org.apache.thrift.protocol.TType.LIST,
new
org.apache.thrift.meta_data.StructMetaData(org.apache.thrift.protocol.TType.STRUCT,
Order.class;
{quote}
> Java compiler generates different meta data depending on order of structures
> in file
>
>
> Key: THRIFT-4086
> URL: https://issues.apache.org/jira/browse/THRIFT-4086
> Project: Thrift
> Issue Type: Bug
> Components: Java - Compiler
>Affects Versions: 0.9.3, 0.10.0
>Reporter: Anton Batylin
>
> When compiling th following thrift code:
> {quote}
> struct Customer {{
> 1: required i32 customer_id,
> 2: required list orders
> }}
> struct Order {
> 1: required i32 order_id,
> }
> {quote}
> compiler generates meta data for {{orders}} field as {{FieldValueMetaData}}:
> {quote}
> tmpMap.put(_Fields.ORDERS, new
> org.apache.thrift.meta_data.FieldMetaData("orders",
> org.apache.thrift.TFieldRequirementType.REQUIRED,
> new
> org.apache.thrift.meta_data.ListMetaData(org.apache.thrift.protocol.TType.LIST,
>
> new
> org.apache.thrift.meta_data.FieldValueMetaData(org.apache.thrift.protocol.TType.STRUCT
> , "Order";
> {quote}
> If structs order is reversed:
> {quote}
> struct Order {
> 1: required i32 order_id,
> }
> struct Customer {
> 1: required i32 customer_id,
> 2: required list orders
> }
> {quote}
> compiler generates meta data for {{orders}} field as {{StructMetaData}}:
> {quote}
> tmpMap.put(_Fields.ORDERS, new
> org.apache.thrift.meta_data.FieldMetaData("orders",
> org.apache.thrift.TFieldRequirementType.REQUIRED,
> new
> org.apache.thrift.meta_data.ListMetaData(org.apache.thrift.protocol.TType.LIST,
>
> new
> org.apache.thrift.meta_data.StructMetaData(org.apache.thrift.protocol.TType.STRUCT,
> Order.class;
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] thrift issue #1156: THRIFT-4011 Use slices for Thrift sets
Github user dcelasun commented on the issue: https://github.com/apache/thrift/pull/1156 @Jens-G Squashed commits and rebased from master. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] thrift issue #1185: Thrift 3369 - Third try to merge SSL c_glib
Github user gadLinux commented on the issue: https://github.com/apache/thrift/pull/1185 It seems it still not fine... Do I have to see something? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] thrift issue #1185: Thrift 3369 - Third try to merge SSL c_glib
Github user gadLinux commented on the issue: https://github.com/apache/thrift/pull/1185 Hi again, As the code is pure c we should be able to support all configurations. It makes me a little surprised to mix mechanism in handshake and negotiation but as far as you know what you are requesting is ok. I'm working passing some certifications PCI, VISA and Master and none of them allows SSL3 to run. Even for handshake. This is the reason why we stick to TLS_1.2. I will check the code a little bit for this way of doing when I have a time slot today. Is there a predefined server that does this way. I suppose that Java is already doing and suppose it's already working since some tests are passing. Can you confirm, please? Thank you a lot for your effort again. Best regards, --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
