TJSONProtocol requires stricter adherence to the rules of TProtocol usage, and some of these rules were broken until recent checkins, but it was going unnoticed because we only tested TCompactProtocol. Now that the TProtocol usage is fixed, we can add tests for TJSONProtocol to check for regressions.
Some protocols (e.g. TJSONProtocol) use different encodings for string and binary data, so treating them as the same type is incorrect.
This fixes a bug that swift2thrift won't work if you don't explicitly provide a non-UNSPECIFIED requiredness on all @ThriftField annotations on all parameters in your service. Though the @ThriftField annotation default for 'requiredness' is UNSPECIFIED, for a method parameter, this should resolve to NONE.
There is a bug that the swift generator cannot handle certain kinds of constants (e.g. maps that have enums for key or value type). This bug will take a bit of restructuring in the generator to fix properly, but some of the users of the generator don't actually need those constants generated at this point, they just need the generator to keep going instead of break and fail to generate any further types. This change does that.
There were too many. Instead of providing every possible combination (and until moving to using a ThriftServerBuilder), I'm just providing static constants DEFAULT_* that you can pass if you don't have a specific value in mind for one of the parameters of the full constructor.
This change allows you to bind ExecutorServices to names, and then select a named executor from the set that was bound using a string property in ThriftServerConfig (thus allowing you to configure the possible exeuctors in your custom Guice module, and then select one by name in your application's config map).
…fied names for a single field" This reverts commit fec0431. There are problems with this change in that I thought "extractName()" always gets the implicit name (not the name in the annotation) but this is not true for ParameterInjections, where the annotation name takes precedence. This is fixable but I'm not sure it's worth it at this time, so I'll revert this diff, making it a warning again to have multiple names for a thrift field.
…es for a single field The existing code was trying to allow for the cases that some appearances of the field might have been explicitly renamed in a @ThriftField annotation, while others may not have been, so there could be conflicts between the set of names retreived by getOrExtractThriftFieldName(). For this reason, conflicting names was only a warning. However it should be an error to have multiple explicit names, or multiple implicit names. This change checks each separately to make sure everything is consistent.
…data for the field