Thrift 1800
Hi Carl, I just added some text like in the sentence mentioned at the beginning of all docstrings in DocTest.thrift to test it. I can provide such a file, but not right now. At this occasion I noticed that Thrift does not accept UTF-8 nor 16 as input. What I'm more interested in is the output you got. Could you send me the generated HTML? Thanks, JensG
[jira] [Commented] (THRIFT-1797) Python implementation of TSimpleJSONProtocol
[ https://issues.apache.org/jira/browse/THRIFT-1797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13538678#comment-13538678 ] Avi Flamholz commented on THRIFT-1797: -- Sorry about that. Any chance you can pull from my branch? g...@github.com:flamholz/thrift.git https://github.com/flamholz/thrift There's nothing new in there except this chance. Avi > Python implementation of TSimpleJSONProtocol > - > > Key: THRIFT-1797 > URL: https://issues.apache.org/jira/browse/THRIFT-1797 > Project: Thrift > Issue Type: New Feature > Components: Python - Library >Affects Versions: 1.2 > Environment: Ubuntu >Reporter: Avi Flamholz > Attachments: python_simple_json_protocol.patch > > > I've attached a patch with a Python implementation of TSimpleJSONProtocol. > This protocol is write-only like the Java implementation. It also fixes a bug > in TJSONProtocol where the context stack was not being popped correctly. This > bug triggered a number of errors in the serialization and deserialization of > Thrift structures to JSON. > The patch also includes a test of TSimpleJSONProtocol. The test checks that > it returns sensible results, but does not check that the wire-format is > equivalent to the Java wire format. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (THRIFT-1708) Add event handlers for processor events
[ https://issues.apache.org/jira/browse/THRIFT-1708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13538655#comment-13538655 ] Jake Farrell commented on THRIFT-1708: -- I'm good with splitting this into sub tickets for any remaining languages > Add event handlers for processor events > --- > > Key: THRIFT-1708 > URL: https://issues.apache.org/jira/browse/THRIFT-1708 > Project: Thrift > Issue Type: New Feature > Components: Java - Library >Affects Versions: 0.9 > Environment: all >Reporter: Andrew Cox >Assignee: Andrew Cox >Priority: Minor > Fix For: 1.0 > > Attachments: thrift-1708-processor-event-handlers.patch > > > Integrates some code we've been using (here at facebook) to add event > handlers that can handle processor events with the server event handlers in > apache thrift. > Processor events include: preRead (before reading arguments), postRead (after > reading arguments), preWrite (before writing results), postWrite (after > writing results), and processorError (when a non-IDL exception is thrown as a > result of an error handling the request). The processor handler is given the > method name and input and output protocol that will be used to process the > request, and can inspect arguments on postRead, and results on pre/postWrite > events. > This change also enables event handlers for non-blocking servers. > Some unit tests are included to exercise the new processor event handlers, > and demonstrate how they can connect with server event handlers. > It also fixes a minor bug I found while testing, where FrameBuffers on > non-blocking servers could have been close()'d more than once. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (THRIFT-1797) Python implementation of TSimpleJSONProtocol
[ https://issues.apache.org/jira/browse/THRIFT-1797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13538591#comment-13538591 ] Carl Yeksigian commented on THRIFT-1797: This patch looks backwards -- it's removing a TSimpleJSONProtocol instead of adding :) Can you fix it and resubmit? > Python implementation of TSimpleJSONProtocol > - > > Key: THRIFT-1797 > URL: https://issues.apache.org/jira/browse/THRIFT-1797 > Project: Thrift > Issue Type: New Feature > Components: Python - Library >Affects Versions: 1.2 > Environment: Ubuntu >Reporter: Avi Flamholz > Attachments: python_simple_json_protocol.patch > > > I've attached a patch with a Python implementation of TSimpleJSONProtocol. > This protocol is write-only like the Java implementation. It also fixes a bug > in TJSONProtocol where the context stack was not being popped correctly. This > bug triggered a number of errors in the serialization and deserialization of > Thrift structures to JSON. > The patch also includes a test of TSimpleJSONProtocol. The test checks that > it returns sensible results, but does not check that the wire-format is > equivalent to the Java wire format. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (THRIFT-1795) Race condition in TThreadedServerPool java implementation
[ https://issues.apache.org/jira/browse/THRIFT-1795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13538582#comment-13538582 ] Carl Yeksigian commented on THRIFT-1795: +1 LGTM > Race condition in TThreadedServerPool java implementation > - > > Key: THRIFT-1795 > URL: https://issues.apache.org/jira/browse/THRIFT-1795 > Project: Thrift > Issue Type: Bug > Components: Java - Library >Affects Versions: 0.6.1, 0.7, 0.8, 0.9 > Environment: RHEL 5.x derivatives, SUSE linux are the systems where > this is intermittently reproducible >Reporter: Venkat Ranganathan > Attachments: Thrift-1795.diff > > > While running unit tests on flume[1], it was discovered that there have been > intermittent failures on Redhat Linux 5.x derivatives and SUSE Linux > environments (or the failures where more pronounced in those environments). > While trying to debug this issue and removing Flume specific issues, I think > there is a race condition in Thrift TThreadPool server implementation. We can > reduce the problem to the basic issue > The server is written in as below in its serve() method > stopped_ = false > while (!stopped_) >try > serve request >except >log message > The stop method (executed typically from another thread) is implemented thus > stopped_ = false > interrupt and cleanup server transport > The basic thought is that stopped_ being volatile, the writes to stopped_ > will always be seen by the reading thread and there is no other > synchronization required, essentially relying on the JSR 133 volatile > description. > The problem is that there is no check in the server run method whether it was > asked to stop or not > For example, the Flume unit test, once again reduced to what is needed for > this discussion, does the following for testing the flume source lifecycle > server.start -- which means starting a thread, whose run method will call > TThreadPoolServer.serve described above > server.stop > It so happens that on Redhat Linux 5.x systems or more specifically with > Linux kernels before the CFQ scheduler, there is a higher chance that > server.stop can run before server thread's serve method is invoked. This > means that the setting of stopped_ flag in the stop method is overwritten in > the serve method.This causes the server to enter an infinite loop and > eventually, the test timeout kicks in > There is an easy fix - just set stopped_ to false in the constructor. But > then it probably violates the contract on the state of a constructed server > object. I see that in couple of other TServer implementations, stopped_ is > initialize to true and only during the listen processing, stopped_ is set to > false. > If preserving this semantics is important, we should introduce another > volatile variable (say started_), and carefully set started_ and stopped_ in > places where we are not sure stopped_ might be overwritten, and check for > both flags also in key locations (right after a thread starts with the > server() method. > This same issue can be evidenced in other variations of TServer > implementations also. > I can provide a patch if it is agreed that this is a bug that needs to be > fixed. I can create a patch introducing a new started_ flag (which respects > the current behavior in some of the classes where stopped_ is initialized to > true), or initialize the Servers to initialize stopped_ to false and then not > reset the stopped_ flag during the server execution (which is simplere and > easy to fix, but makes a server just constructed to be not in stopped state). > I don't know how important it is to maintain that behavior or if there is > any reliance on that behavior > Thanks > Venkat -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (THRIFT-1795) Race condition in TThreadedServerPool java implementation
[ https://issues.apache.org/jira/browse/THRIFT-1795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13538567#comment-13538567 ] Venkat Ranganathan commented on THRIFT-1795: I don't have contributor access to Thrift - so I can't assign the bug to myself or mark state as patch available. Please review the current patch Thanks Venkat > Race condition in TThreadedServerPool java implementation > - > > Key: THRIFT-1795 > URL: https://issues.apache.org/jira/browse/THRIFT-1795 > Project: Thrift > Issue Type: Bug > Components: Java - Library >Affects Versions: 0.6.1, 0.7, 0.8, 0.9 > Environment: RHEL 5.x derivatives, SUSE linux are the systems where > this is intermittently reproducible >Reporter: Venkat Ranganathan > Attachments: Thrift-1795.diff > > > While running unit tests on flume[1], it was discovered that there have been > intermittent failures on Redhat Linux 5.x derivatives and SUSE Linux > environments (or the failures where more pronounced in those environments). > While trying to debug this issue and removing Flume specific issues, I think > there is a race condition in Thrift TThreadPool server implementation. We can > reduce the problem to the basic issue > The server is written in as below in its serve() method > stopped_ = false > while (!stopped_) >try > serve request >except >log message > The stop method (executed typically from another thread) is implemented thus > stopped_ = false > interrupt and cleanup server transport > The basic thought is that stopped_ being volatile, the writes to stopped_ > will always be seen by the reading thread and there is no other > synchronization required, essentially relying on the JSR 133 volatile > description. > The problem is that there is no check in the server run method whether it was > asked to stop or not > For example, the Flume unit test, once again reduced to what is needed for > this discussion, does the following for testing the flume source lifecycle > server.start -- which means starting a thread, whose run method will call > TThreadPoolServer.serve described above > server.stop > It so happens that on Redhat Linux 5.x systems or more specifically with > Linux kernels before the CFQ scheduler, there is a higher chance that > server.stop can run before server thread's serve method is invoked. This > means that the setting of stopped_ flag in the stop method is overwritten in > the serve method.This causes the server to enter an infinite loop and > eventually, the test timeout kicks in > There is an easy fix - just set stopped_ to false in the constructor. But > then it probably violates the contract on the state of a constructed server > object. I see that in couple of other TServer implementations, stopped_ is > initialize to true and only during the listen processing, stopped_ is set to > false. > If preserving this semantics is important, we should introduce another > volatile variable (say started_), and carefully set started_ and stopped_ in > places where we are not sure stopped_ might be overwritten, and check for > both flags also in key locations (right after a thread starts with the > server() method. > This same issue can be evidenced in other variations of TServer > implementations also. > I can provide a patch if it is agreed that this is a bug that needs to be > fixed. I can create a patch introducing a new started_ flag (which respects > the current behavior in some of the classes where stopped_ is initialized to > true), or initialize the Servers to initialize stopped_ to false and then not > reset the stopped_ flag during the server execution (which is simplere and > easy to fix, but makes a server just constructed to be not in stopped state). > I don't know how important it is to maintain that behavior or if there is > any reliance on that behavior > Thanks > Venkat -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (THRIFT-1026) C# default value code generation problem
[
https://issues.apache.org/jira/browse/THRIFT-1026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carl Yeksigian resolved THRIFT-1026.
Resolution: Fixed
> C# default value code generation problem
>
>
> Key: THRIFT-1026
> URL: https://issues.apache.org/jira/browse/THRIFT-1026
> Project: Thrift
> Issue Type: Bug
> Components: C# - Compiler
>Affects Versions: 0.5
> Environment: Windows, Mac
>Reporter: William Blinn
>
> I have a thrift file that looks like this:
> {code}
> // Time stamp with a timezone specification for normalization.
> struct DateTimeZone
> {
> 1: i64 ticks,
> 2: optional string timeZone = "UTC",
> }
> {code}
> When I generate C#, it produces code like this:
> {code}
> [Serializable]
> public partial class DateTimeZone : TBase
> {
> private long _ticks;
> private string _timeZone;
> public long Ticks
> {
> get
> {
> return _ticks;
> }
> set
> {
> __isset.ticks = true;
> this._ticks = value;
> }
> }
> public string TimeZone
> {
> get
> {
> return _timeZone;
> }
> set
> {
> __isset.timeZone = true;
> this._timeZone = value;
> }
> }
> public Isset __isset;
> [Serializable]
> public struct Isset {
> public bool ticks;
> public bool timeZone;
> }
> public DateTimeZone() {
> this.timeZone = "UTC";
> }
> ...
> {code}
> The constructor, which sets the default value should be this.TimeZone = "UTC"
> because the property is TimeZone, not timeZone. The constructor should set
> the property rather than the field so that __isset is marked properly.
> The compile error I get when I try to compile the code that thrift generates
> is like this:
> {code}
> [csc] d:\code\Thrift\Generated\DateTimeZone.cs(59,12): error CS1061:
> 'Thrift.Generated.DateTimeZone' does not contain a definition for 'timeZone'
> and no extension method 'timeZone' accepting a first argument of type
> 'Thrift.Generated.DateTimeZone' could be found (are you missing a using
> directive or an assembly reference?)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (THRIFT-1097) Do not fail silently when IDL contains semi-colons instead of commas
[
https://issues.apache.org/jira/browse/THRIFT-1097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carl Yeksigian resolved THRIFT-1097.
Resolution: Fixed
> Do not fail silently when IDL contains semi-colons instead of commas
>
>
> Key: THRIFT-1097
> URL: https://issues.apache.org/jira/browse/THRIFT-1097
> Project: Thrift
> Issue Type: Improvement
> Components: C# - Compiler
>Affects Versions: 0.6
> Environment: Windows 7 (x64) .NET 4.0
>Reporter: John Ruiz
>Priority: Minor
> Labels: thrift
>
> GIVEN
> 1. The following IDL file (Notification.thrift):
> namespace my.example
> struct Notification {
> 1: required string id;
> 2: optional string respondsTo;
> 3: required string topic;
> 4: required i64 created;
> 5: optional string type;
> 6: optional string body;
> }
> WHEN
> 1. thrift -v --gen csharp:log_unexpected,hashcode Notification.thrift
> OBSERVED OUTCOME
> I see the following in the console:
> Scanning /Notification.thrift for includes
> Parsing /Notification.thrift for types
> Program: /Notification.thrift
> Generating "csharp:log_unexpected,hashcode"
> a gen-csharp folder is generated, but is completely empty.
> EXPECTED OUTCOME
> The console should display a message stating that it failed to generate code
> because of a problem in the IDL.
> REMARKS
> When I saw my error and changed the semi-colons to commas, everything worked
> as expected.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (THRIFT-1212) Members capital case conflict
[
https://issues.apache.org/jira/browse/THRIFT-1212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13538536#comment-13538536
]
Carl Yeksigian commented on THRIFT-1212:
I think it makes sense to disallow the name of a member from being the same as
the name of the class (in any capitalization, which is why this is breaking for
C#). I feel like that would force better naming for structs, or the use of a
typedef instead.
> Members capital case conflict
> -
>
> Key: THRIFT-1212
> URL: https://issues.apache.org/jira/browse/THRIFT-1212
> Project: Thrift
> Issue Type: Bug
> Components: C# - Compiler
>Affects Versions: 0.6.1
> Environment: Windows 7
>Reporter: Vadim Chekan
>Priority: Minor
>
> When generating "csharp" target off the following structure:
> ===
> struct Order {
> 1: string col, // sort column name
> 2: i32order // asc(1) or desc(0)
> }
> ===
> the code is generated:
> class Order { public int Order ...
> This code fails to compile in C# compiler because member name is the same as
> containing clsss name, which is invalid in C#.
> Perhaps there must be a check when generating members and if capitalized
> member name turns out to be the same as containing class name, then prepend
> it with underscore.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (THRIFT-1026) C# default value code generation problem
[
https://issues.apache.org/jira/browse/THRIFT-1026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13538537#comment-13538537
]
Carl Yeksigian commented on THRIFT-1026:
This is fixed in the current version.
> C# default value code generation problem
>
>
> Key: THRIFT-1026
> URL: https://issues.apache.org/jira/browse/THRIFT-1026
> Project: Thrift
> Issue Type: Bug
> Components: C# - Compiler
>Affects Versions: 0.5
> Environment: Windows, Mac
>Reporter: William Blinn
>
> I have a thrift file that looks like this:
> {code}
> // Time stamp with a timezone specification for normalization.
> struct DateTimeZone
> {
> 1: i64 ticks,
> 2: optional string timeZone = "UTC",
> }
> {code}
> When I generate C#, it produces code like this:
> {code}
> [Serializable]
> public partial class DateTimeZone : TBase
> {
> private long _ticks;
> private string _timeZone;
> public long Ticks
> {
> get
> {
> return _ticks;
> }
> set
> {
> __isset.ticks = true;
> this._ticks = value;
> }
> }
> public string TimeZone
> {
> get
> {
> return _timeZone;
> }
> set
> {
> __isset.timeZone = true;
> this._timeZone = value;
> }
> }
> public Isset __isset;
> [Serializable]
> public struct Isset {
> public bool ticks;
> public bool timeZone;
> }
> public DateTimeZone() {
> this.timeZone = "UTC";
> }
> ...
> {code}
> The constructor, which sets the default value should be this.TimeZone = "UTC"
> because the property is TimeZone, not timeZone. The constructor should set
> the property rather than the field so that __isset is marked properly.
> The compile error I get when I try to compile the code that thrift generates
> is like this:
> {code}
> [csc] d:\code\Thrift\Generated\DateTimeZone.cs(59,12): error CS1061:
> 'Thrift.Generated.DateTimeZone' does not contain a definition for 'timeZone'
> and no extension method 'timeZone' accepting a first argument of type
> 'Thrift.Generated.DateTimeZone' could be found (are you missing a using
> directive or an assembly reference?)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (THRIFT-1097) Do not fail silently when IDL contains semi-colons instead of commas
[
https://issues.apache.org/jira/browse/THRIFT-1097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13538535#comment-13538535
]
Carl Yeksigian commented on THRIFT-1097:
The problem with the current version is the namespace isn't for a specific
language. Not sure if this was fixed earlier, or not. Using "namespace csharp
my.example" works.
> Do not fail silently when IDL contains semi-colons instead of commas
>
>
> Key: THRIFT-1097
> URL: https://issues.apache.org/jira/browse/THRIFT-1097
> Project: Thrift
> Issue Type: Improvement
> Components: C# - Compiler
>Affects Versions: 0.6
> Environment: Windows 7 (x64) .NET 4.0
>Reporter: John Ruiz
>Priority: Minor
> Labels: thrift
>
> GIVEN
> 1. The following IDL file (Notification.thrift):
> namespace my.example
> struct Notification {
> 1: required string id;
> 2: optional string respondsTo;
> 3: required string topic;
> 4: required i64 created;
> 5: optional string type;
> 6: optional string body;
> }
> WHEN
> 1. thrift -v --gen csharp:log_unexpected,hashcode Notification.thrift
> OBSERVED OUTCOME
> I see the following in the console:
> Scanning /Notification.thrift for includes
> Parsing /Notification.thrift for types
> Program: /Notification.thrift
> Generating "csharp:log_unexpected,hashcode"
> a gen-csharp folder is generated, but is completely empty.
> EXPECTED OUTCOME
> The console should display a message stating that it failed to generate code
> because of a problem in the IDL.
> REMARKS
> When I saw my error and changed the semi-colons to commas, everything worked
> as expected.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (THRIFT-1802) Java: Remove consume from THttpClient
Carl Yeksigian created THRIFT-1802: -- Summary: Java: Remove consume from THttpClient Key: THRIFT-1802 URL: https://issues.apache.org/jira/browse/THRIFT-1802 Project: Thrift Issue Type: Improvement Affects Versions: 1.0 Reporter: Carl Yeksigian Priority: Minor When Android has a compatible version of the EntityUtils, remove the consume call related to THRIFT-1641, and use EntityUtils.consume instead. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (THRIFT-1641) Thrift 0.8 not compatible with Android HttpClient
[ https://issues.apache.org/jira/browse/THRIFT-1641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13538524#comment-13538524 ] Carl Yeksigian commented on THRIFT-1641: +1 Opening a new ticket to remove this code when Android has a compatible version of EntityUtils. > Thrift 0.8 not compatible with Android HttpClient > - > > Key: THRIFT-1641 > URL: https://issues.apache.org/jira/browse/THRIFT-1641 > Project: Thrift > Issue Type: Bug > Components: Java - Library >Affects Versions: 0.8, 0.9 >Reporter: Darin Tay > Attachments: fix-thrift-1641.patch > > > In Thrift 0.8, THttpClient.java added a call to EntityUtils.consume. This > was added in HttpClient 4.1, whereas Android only supports 4.0. > Additionally, while it's possible to package a newer version of HttpClient > with your Android project, it has to be in a different package. > This means the Thrift Java library no longer works on Android if THttpClient > is used. > Since the code behind EntityUtils.consume is pretty trivial (just close the > stream if it's streaming), would it be possible to not use this method? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (THRIFT-1800) Documentation text not escaped correctly when rendered to HTML
[ https://issues.apache.org/jira/browse/THRIFT-1800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13538518#comment-13538518 ] Carl Yeksigian commented on THRIFT-1800: Can you change test/DocTest.thrift to demonstrate the change that you made? I'm not able to get it to properly escape the characters (instead, it is adding additional bogus characters). > Documentation text not escaped correctly when rendered to HTML > -- > > Key: THRIFT-1800 > URL: https://issues.apache.org/jira/browse/THRIFT-1800 > Project: Thrift > Issue Type: Bug >Reporter: Jens Geyer >Assignee: Jens Geyer > Fix For: 1.0 > > Attachments: > THRIFT-1800_Documentation_text_not_escaped_correctly_when_rendered_to_HTML > .patch > > > Comments containing non-ascii characters (like for example the swedish "Vi > mäter temperaturer i °C") show up incorrectly in the generated HTML file. > Only a handful of characters is encoded at all, and only at a few rare > occasions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (THRIFT-1641) Thrift 0.8 not compatible with Android HttpClient
[ https://issues.apache.org/jira/browse/THRIFT-1641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitali Lovich updated THRIFT-1641: -- Attachment: fix-thrift-1641.patch this fixes the issue > Thrift 0.8 not compatible with Android HttpClient > - > > Key: THRIFT-1641 > URL: https://issues.apache.org/jira/browse/THRIFT-1641 > Project: Thrift > Issue Type: Bug > Components: Java - Library >Affects Versions: 0.8, 0.9 >Reporter: Darin Tay > Attachments: fix-thrift-1641.patch > > > In Thrift 0.8, THttpClient.java added a call to EntityUtils.consume. This > was added in HttpClient 4.1, whereas Android only supports 4.0. > Additionally, while it's possible to package a newer version of HttpClient > with your Android project, it has to be in a different package. > This means the Thrift Java library no longer works on Android if THttpClient > is used. > Since the code behind EntityUtils.consume is pretty trivial (just close the > stream if it's streaming), would it be possible to not use this method? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (THRIFT-1708) Add event handlers for processor events
[ https://issues.apache.org/jira/browse/THRIFT-1708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13538481#comment-13538481 ] Diwaker Gupta commented on THRIFT-1708: --- [~bterm], can we break this up into 3 separate patches for C++, Java and Python? I'd love to see this for Java asap and we needn't be blocked on support in other languages right? > Add event handlers for processor events > --- > > Key: THRIFT-1708 > URL: https://issues.apache.org/jira/browse/THRIFT-1708 > Project: Thrift > Issue Type: New Feature > Components: Java - Library >Affects Versions: 0.9 > Environment: all >Reporter: Andrew Cox >Assignee: Andrew Cox >Priority: Minor > Fix For: 1.0 > > Attachments: thrift-1708-processor-event-handlers.patch > > > Integrates some code we've been using (here at facebook) to add event > handlers that can handle processor events with the server event handlers in > apache thrift. > Processor events include: preRead (before reading arguments), postRead (after > reading arguments), preWrite (before writing results), postWrite (after > writing results), and processorError (when a non-IDL exception is thrown as a > result of an error handling the request). The processor handler is given the > method name and input and output protocol that will be used to process the > request, and can inspect arguments on postRead, and results on pre/postWrite > events. > This change also enables event handlers for non-blocking servers. > Some unit tests are included to exercise the new processor event handlers, > and demonstrate how they can connect with server event handlers. > It also fixes a minor bug I found while testing, where FrameBuffers on > non-blocking servers could have been close()'d more than once. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (THRIFT-1641) Thrift 0.8 not compatible with Android HttpClient
[ https://issues.apache.org/jira/browse/THRIFT-1641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13538474#comment-13538474 ] Vitali Lovich commented on THRIFT-1641: --- I too am seeing this issue & it's still present in 0.9. I have to manually recompile the libthrift.jar to be compatible with Android. > Thrift 0.8 not compatible with Android HttpClient > - > > Key: THRIFT-1641 > URL: https://issues.apache.org/jira/browse/THRIFT-1641 > Project: Thrift > Issue Type: Bug > Components: Java - Library >Affects Versions: 0.8 >Reporter: Darin Tay > > In Thrift 0.8, THttpClient.java added a call to EntityUtils.consume. This > was added in HttpClient 4.1, whereas Android only supports 4.0. > Additionally, while it's possible to package a newer version of HttpClient > with your Android project, it has to be in a different package. > This means the Thrift Java library no longer works on Android if THttpClient > is used. > Since the code behind EntityUtils.consume is pretty trivial (just close the > stream if it's streaming), would it be possible to not use this method? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (THRIFT-1641) Thrift 0.8 not compatible with Android HttpClient
[ https://issues.apache.org/jira/browse/THRIFT-1641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitali Lovich updated THRIFT-1641: -- Affects Version/s: 0.9 > Thrift 0.8 not compatible with Android HttpClient > - > > Key: THRIFT-1641 > URL: https://issues.apache.org/jira/browse/THRIFT-1641 > Project: Thrift > Issue Type: Bug > Components: Java - Library >Affects Versions: 0.8, 0.9 >Reporter: Darin Tay > > In Thrift 0.8, THttpClient.java added a call to EntityUtils.consume. This > was added in HttpClient 4.1, whereas Android only supports 4.0. > Additionally, while it's possible to package a newer version of HttpClient > with your Android project, it has to be in a different package. > This means the Thrift Java library no longer works on Android if THttpClient > is used. > Since the code behind EntityUtils.consume is pretty trivial (just close the > stream if it's streaming), would it be possible to not use this method? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (THRIFT-1801) Sync up TApplicationException codes across languages and thrift implementations
[ https://issues.apache.org/jira/browse/THRIFT-1801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13538473#comment-13538473 ] Roger Meier commented on THRIFT-1801: - Fully agree, we need an improved Exception handling and I like to get some more contributions from your side. We recently got this input here: THRIFT-1761 Make generated exceptions have a common unique parent What do you think on this? Which cross language test suite do you use? I started this THRIFT-847 ran via test/test.sh all the best! roger ;-r > Sync up TApplicationException codes across languages and thrift > implementations > --- > > Key: THRIFT-1801 > URL: https://issues.apache.org/jira/browse/THRIFT-1801 > Project: Thrift > Issue Type: Task >Affects Versions: 1.0 > Environment: all >Reporter: Andrew Cox >Assignee: Andrew Cox > Fix For: 1.0 > > Attachments: THRIFT-1801.1.patch > > > Two issues with TApplicationException codes: > 1) some languages contained incomplete lists of existing > TApplicationException codes > 2) internally in Facebook thrift servers, we had reserved a few extra error > codes for TApplicationException, and those error codes were then claimed here > for different uses. this causes conflicts when some clients that know about > one set of codes communicates with servers that know about a different set of > codes. I've reassigned our internal error code numbers to make space for the > ones in more recent thrift code, but to try prevent this from happening > again, I'd like to add our own codes to reserve them (these currently won't > have any other mention in the thrift libraries right now than being in > TApplicationException, but they may eventually be used when we push more of > this internal code out). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (THRIFT-1801) Sync up TApplicationException codes across languages and thrift implementations
[ https://issues.apache.org/jira/browse/THRIFT-1801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Cox updated THRIFT-1801: --- Attachment: THRIFT-1801.1.patch > Sync up TApplicationException codes across languages and thrift > implementations > --- > > Key: THRIFT-1801 > URL: https://issues.apache.org/jira/browse/THRIFT-1801 > Project: Thrift > Issue Type: Task >Affects Versions: 1.0 > Environment: all >Reporter: Andrew Cox >Assignee: Andrew Cox > Fix For: 1.0 > > Attachments: THRIFT-1801.1.patch > > > Two issues with TApplicationException codes: > 1) some languages contained incomplete lists of existing > TApplicationException codes > 2) internally in Facebook thrift servers, we had reserved a few extra error > codes for TApplicationException, and those error codes were then claimed here > for different uses. this causes conflicts when some clients that know about > one set of codes communicates with servers that know about a different set of > codes. I've reassigned our internal error code numbers to make space for the > ones in more recent thrift code, but to try prevent this from happening > again, I'd like to add our own codes to reserve them (these currently won't > have any other mention in the thrift libraries right now than being in > TApplicationException, but they may eventually be used when we push more of > this internal code out). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (THRIFT-1799) Option to generate HTML in "standalone mode"
[ https://issues.apache.org/jira/browse/THRIFT-1799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer resolved THRIFT-1799. Resolution: Fixed > Option to generate HTML in "standalone mode" > > > Key: THRIFT-1799 > URL: https://issues.apache.org/jira/browse/THRIFT-1799 > Project: Thrift > Issue Type: Improvement >Reporter: Jens Geyer >Assignee: Jens Geyer > Fix For: 1.0 > > Attachments: > THRIFT-1799_Option_to_generate_HTML_in_standalone_mode.patch, > THRIFT-1799_Option_to_generate_HTML_in_standalone_mode-v2.patch > > > Improvements to HTML Generator > * Removed HTML page name at links for targets located in the > same file > * Option added to embed CSS inline instead of style.css. > Both improvements are quite helpful in some situations, e.g. when the HTML is > accessed in a way other than via the original file name, or when the separate > CSS file cannot be provided along with the HTML for some reason. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (THRIFT-1799) Option to generate HTML in "standalone mode"
[ https://issues.apache.org/jira/browse/THRIFT-1799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13538467#comment-13538467 ] Jens Geyer commented on THRIFT-1799: Committed. Thanks Roger and Carl! > Option to generate HTML in "standalone mode" > > > Key: THRIFT-1799 > URL: https://issues.apache.org/jira/browse/THRIFT-1799 > Project: Thrift > Issue Type: Improvement >Reporter: Jens Geyer >Assignee: Jens Geyer > Fix For: 1.0 > > Attachments: > THRIFT-1799_Option_to_generate_HTML_in_standalone_mode.patch, > THRIFT-1799_Option_to_generate_HTML_in_standalone_mode-v2.patch > > > Improvements to HTML Generator > * Removed HTML page name at links for targets located in the > same file > * Option added to embed CSS inline instead of style.css. > Both improvements are quite helpful in some situations, e.g. when the HTML is > accessed in a way other than via the original file name, or when the separate > CSS file cannot be provided along with the HTML for some reason. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (THRIFT-1799) Option to generate HTML in "standalone mode"
[ https://issues.apache.org/jira/browse/THRIFT-1799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13538466#comment-13538466 ] Roger Meier commented on THRIFT-1799: - +1 please commit. > Option to generate HTML in "standalone mode" > > > Key: THRIFT-1799 > URL: https://issues.apache.org/jira/browse/THRIFT-1799 > Project: Thrift > Issue Type: Improvement >Reporter: Jens Geyer >Assignee: Jens Geyer > Fix For: 1.0 > > Attachments: > THRIFT-1799_Option_to_generate_HTML_in_standalone_mode.patch, > THRIFT-1799_Option_to_generate_HTML_in_standalone_mode-v2.patch > > > Improvements to HTML Generator > * Removed HTML page name at links for targets located in the > same file > * Option added to embed CSS inline instead of style.css. > Both improvements are quite helpful in some situations, e.g. when the HTML is > accessed in a way other than via the original file name, or when the separate > CSS file cannot be provided along with the HTML for some reason. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (THRIFT-1800) Documentation text not escaped correctly when rendered to HTML
[ https://issues.apache.org/jira/browse/THRIFT-1800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer updated THRIFT-1800: --- Attachment: THRIFT-1800_Documentation_text_not_escaped_correctly_when_rendered_to_HTML .patch The careful observer will notice that I didn't use the escape_[] table by intention. :-) > Documentation text not escaped correctly when rendered to HTML > -- > > Key: THRIFT-1800 > URL: https://issues.apache.org/jira/browse/THRIFT-1800 > Project: Thrift > Issue Type: Bug >Reporter: Jens Geyer >Assignee: Jens Geyer > Fix For: 1.0 > > Attachments: > THRIFT-1800_Documentation_text_not_escaped_correctly_when_rendered_to_HTML > .patch > > > Comments containing non-ascii characters (like for example the swedish "Vi > mäter temperaturer i °C") show up incorrectly in the generated HTML file. > Only a handful of characters is encoded at all, and only at a few rare > occasions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (THRIFT-1801) Sync up TApplicationException codes across languages and thrift implementations
Andrew Cox created THRIFT-1801: -- Summary: Sync up TApplicationException codes across languages and thrift implementations Key: THRIFT-1801 URL: https://issues.apache.org/jira/browse/THRIFT-1801 Project: Thrift Issue Type: Task Affects Versions: 1.0 Environment: all Reporter: Andrew Cox Assignee: Andrew Cox Fix For: 1.0 Two issues with TApplicationException codes: 1) some languages contained incomplete lists of existing TApplicationException codes 2) internally in Facebook thrift servers, we had reserved a few extra error codes for TApplicationException, and those error codes were then claimed here for different uses. this causes conflicts when some clients that know about one set of codes communicates with servers that know about a different set of codes. I've reassigned our internal error code numbers to make space for the ones in more recent thrift code, but to try prevent this from happening again, I'd like to add our own codes to reserve them (these currently won't have any other mention in the thrift libraries right now than being in TApplicationException, but they may eventually be used when we push more of this internal code out). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (THRIFT-1799) Option to generate HTML in "standalone mode"
[ https://issues.apache.org/jira/browse/THRIFT-1799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer updated THRIFT-1799: --- Attachment: THRIFT-1799_Option_to_generate_HTML_in_standalone_mode-v2.patch Cleaned up patch, no other changes. > Option to generate HTML in "standalone mode" > > > Key: THRIFT-1799 > URL: https://issues.apache.org/jira/browse/THRIFT-1799 > Project: Thrift > Issue Type: Improvement >Reporter: Jens Geyer >Assignee: Jens Geyer > Fix For: 1.0 > > Attachments: > THRIFT-1799_Option_to_generate_HTML_in_standalone_mode.patch, > THRIFT-1799_Option_to_generate_HTML_in_standalone_mode-v2.patch > > > Improvements to HTML Generator > * Removed HTML page name at links for targets located in the > same file > * Option added to embed CSS inline instead of style.css. > Both improvements are quite helpful in some situations, e.g. when the HTML is > accessed in a way other than via the original file name, or when the separate > CSS file cannot be provided along with the HTML for some reason. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (THRIFT-1746) provide a SPDX file
[ https://issues.apache.org/jira/browse/THRIFT-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13538450#comment-13538450 ] Roger Meier commented on THRIFT-1746: - just committed the first patch! > provide a SPDX file > --- > > Key: THRIFT-1746 > URL: https://issues.apache.org/jira/browse/THRIFT-1746 > Project: Thrift > Issue Type: Improvement >Reporter: Roger Meier >Priority: Minor > Attachments: THRIFT-1746_remove_obsolete_old_thrift_license.patch > > > Let's try if it is feasible to have a [spdx|http://spdx.org/] file created by > Apache Thrift. > And check what licenses we have, see spdx-licenselist. > http://spdx.org/licenses/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (THRIFT-1800) Documentation text not escaped correctly when rendered to HTML
Jens Geyer created THRIFT-1800: -- Summary: Documentation text not escaped correctly when rendered to HTML Key: THRIFT-1800 URL: https://issues.apache.org/jira/browse/THRIFT-1800 Project: Thrift Issue Type: Bug Reporter: Jens Geyer Assignee: Jens Geyer Fix For: 1.0 Comments containing non-ascii characters (like for example the swedish "Vi mäter temperaturer i °C") show up incorrectly in the generated HTML file. Only a handful of characters is encoded at all, and only at a few rare occasions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (THRIFT-1799) Option to generate HTML in "standalone mode"
[ https://issues.apache.org/jira/browse/THRIFT-1799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13538422#comment-13538422 ] Carl Yeksigian commented on THRIFT-1799: The patch seems to be looking into the .git directories -- how are you generating it? If you use git diff, it will create the patch without the .git directories, with respect to the current head (git diff --cached if you have staged your commits). +1 on the change. > Option to generate HTML in "standalone mode" > > > Key: THRIFT-1799 > URL: https://issues.apache.org/jira/browse/THRIFT-1799 > Project: Thrift > Issue Type: Improvement >Reporter: Jens Geyer >Assignee: Jens Geyer > Fix For: 1.0 > > Attachments: > THRIFT-1799_Option_to_generate_HTML_in_standalone_mode.patch > > > Improvements to HTML Generator > * Removed HTML page name at links for targets located in the > same file > * Option added to embed CSS inline instead of style.css. > Both improvements are quite helpful in some situations, e.g. when the HTML is > accessed in a way other than via the original file name, or when the separate > CSS file cannot be provided along with the HTML for some reason. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (THRIFT-1799) Option to generate HTML in "standalone mode"
[ https://issues.apache.org/jira/browse/THRIFT-1799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13538416#comment-13538416 ] Roger Meier commented on THRIFT-1799: - +1 > Option to generate HTML in "standalone mode" > > > Key: THRIFT-1799 > URL: https://issues.apache.org/jira/browse/THRIFT-1799 > Project: Thrift > Issue Type: Improvement >Reporter: Jens Geyer >Assignee: Jens Geyer > Fix For: 1.0 > > Attachments: > THRIFT-1799_Option_to_generate_HTML_in_standalone_mode.patch > > > Improvements to HTML Generator > * Removed HTML page name at links for targets located in the > same file > * Option added to embed CSS inline instead of style.css. > Both improvements are quite helpful in some situations, e.g. when the HTML is > accessed in a way other than via the original file name, or when the separate > CSS file cannot be provided along with the HTML for some reason. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (THRIFT-1769) unions can't have required fields (C++)
[ https://issues.apache.org/jira/browse/THRIFT-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer resolved THRIFT-1769. Resolution: Invalid Issue has been fixed in a more general way by THRIFT-1768. > unions can't have required fields (C++) > --- > > Key: THRIFT-1769 > URL: https://issues.apache.org/jira/browse/THRIFT-1769 > Project: Thrift > Issue Type: Bug > Components: C++ - Compiler >Affects Versions: 0.8, 0.9 >Reporter: Jens Geyer >Assignee: Jens Geyer > Fix For: 1.0 > > > Required fields within unions should be treaten as optional, the union > construct would not make much sense otherwise. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (THRIFT-1769) unions can't have required fields (C++)
[ https://issues.apache.org/jira/browse/THRIFT-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer updated THRIFT-1769: --- Attachment: (was: THRIFT-1769_unions_cant_have_required_fields_CPP.patch) > unions can't have required fields (C++) > --- > > Key: THRIFT-1769 > URL: https://issues.apache.org/jira/browse/THRIFT-1769 > Project: Thrift > Issue Type: Bug > Components: C++ - Compiler >Affects Versions: 0.8, 0.9 >Reporter: Jens Geyer >Assignee: Jens Geyer > Fix For: 1.0 > > > Required fields within unions should be treaten as optional, the union > construct would not make much sense otherwise. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (THRIFT-1799) Option to generate HTML in "standalone mode"
[ https://issues.apache.org/jira/browse/THRIFT-1799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer updated THRIFT-1799: --- Attachment: THRIFT-1799_Option_to_generate_HTML_in_standalone_mode.patch > Option to generate HTML in "standalone mode" > > > Key: THRIFT-1799 > URL: https://issues.apache.org/jira/browse/THRIFT-1799 > Project: Thrift > Issue Type: Improvement >Reporter: Jens Geyer >Assignee: Jens Geyer > Fix For: 1.0 > > Attachments: > THRIFT-1799_Option_to_generate_HTML_in_standalone_mode.patch > > > Improvements to HTML Generator > * Removed HTML page name at links for targets located in the > same file > * Option added to embed CSS inline instead of style.css. > Both improvements are quite helpful in some situations, e.g. when the HTML is > accessed in a way other than via the original file name, or when the separate > CSS file cannot be provided along with the HTML for some reason. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (THRIFT-1799) Option to generate HTML in "standalone mode"
Jens Geyer created THRIFT-1799: -- Summary: Option to generate HTML in "standalone mode" Key: THRIFT-1799 URL: https://issues.apache.org/jira/browse/THRIFT-1799 Project: Thrift Issue Type: Improvement Reporter: Jens Geyer Assignee: Jens Geyer Fix For: 1.0 Improvements to HTML Generator * Removed HTML page name at links for targets located in the same file * Option added to embed CSS inline instead of style.css. Both improvements are quite helpful in some situations, e.g. when the HTML is accessed in a way other than via the original file name, or when the separate CSS file cannot be provided along with the HTML for some reason. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
