Git Product home page Git Product logo

swift's Introduction

Project Status: 🚨 Unmaintained 🚨

This project is archived and no longer maintained. At the time of archiving, open issues and pull requests were closed and tagged with 2018-05-archive. For pre-existing users who need an open source alternative, we recommend taking a look at airlift/drift.

Swift

Swift is an easy-to-use, annotation-based Java library for creating Thrift serializable types and services.

Swift Codec

Swift Codec is a simple library specifying how Java objects are converted to and from Thrift. This library is similar to JaxB (XML) and Jackson (JSON), but for Thrift. Swift codec supports field, method, constructor, and builder injection. For example:

@ThriftStruct
public class LogEntry
{
    private final String category;
    private final String message;

    @ThriftConstructor
    public LogEntry(String category, String message)
    {
        this.category = category;
        this.message = message;
    }

    @ThriftField(1)
    public String getCategory()
    {
        return category;
    }

    @ThriftField(2)
    public String getMessage()
    {
        return message;
    }
}

Swift Service

Swift Service is a simple library annotating services to be exported with Thrift. For example:

@ThriftService("scribe")
public class InMemoryScribe
{
    private final List<LogEntry> messages = new ArrayList<>();

    public List<LogEntry> getMessages()
    {
        return messages;
    }

    @ThriftMethod("Log")
    public ResultCode log(List<LogEntry> messages)
    {
        this.messages.addAll(messages);
        return ResultCode.OK;
    }
}

Swift Generator

Swift Generator is a library that creates Java code usable with the Swift codec from Thrift IDL files and vice versa.

Swift Generator CLI and Swift2Thrift Generator CLI are command-line front-ends to this generator.

Swift Maven plugin

Swift Maven plugin allows using the code generator from a maven build and generate source code on the fly.

swift's People

Contributors

alandau avatar alex-sherwin avatar andrewcox avatar bgould avatar cberner avatar dain avatar electrum avatar erichwang avatar groys avatar hgschmie avatar jesboat avatar l3fang avatar martint avatar mdzhou avatar phonyphonecall avatar ronnienigash avatar ryandm avatar scottgoldwater avatar shootingsyh avatar siyengar avatar skreyen avatar tageorgiou avatar tomdz avatar twilliamson avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

swift's Issues

Better handling for Thrift namespaces in swift generator

We need to do better handling of namespaces here. I think it would make sense to have identifiers become a 'symbol' when they are first seen, instead of just a string (and have the symbol contain two strings: namespace name, and type name - namespace name would get set to the current filename if there wasn't one parsed explicitly) so that a default namespace is never needed here.

See discussion here andrewcox@8a0b2b5#commitcomment-4268219 for details

Support priorities on methods

fbthrift's C++ ThriftServer has support for setting priorities on incoming messages, we should be able to support that in swift as well.

Service implementor cannot extend multiple ThriftServices interfaces.

I have a class that implements two different interfaces that are both annotated as ThriftService objects. When passing an instance of this class to ThriftServiceProcessor, it will fail due to implementing multiple services. This is useful functionality, per se, to limit clients from having access to all the methods. Can we simply remove the check here?

Caused by: java.lang.IllegalStateException: service JobStatsStore extends multiple services
at com.google.common.base.Preconditions.checkState(Preconditions.java:150)
at com.facebook.swift.service.metadata.ThriftServiceMetadata.(ThriftServiceMetadata.java:87)
at com.facebook.swift.service.ThriftServiceProcessor.(ThriftServiceProcessor.java:75)
at com.facebook.swift.service.ThriftServiceProcessor.(ThriftServiceProcessor.java:63)

Swift-service is exporting its TestNG surefire configuration

It appears that swift-service is exporting its surefire configuration to downstream maven projects.

In a project with a dependency on swift-annotations 0.7.0-SNAPSHOT and junit 4.x tests, the tests run ok with surefire

$ mvn test
...
[INFO] --- maven-surefire-plugin:2.14:test (default-test) @ project ---
-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running project.Junit4xTest
Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.333 sec

Results :

Tests run: 10, Failures: 0, Errors: 0, Skipped: 0

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS

After adding a new dependency on swift-service 0.7.0-SNAPSHOT for guice-related classes, the project no longer runs any unit tests

$ mvn test
...
[INFO] --- maven-surefire-plugin:2.14:test (default-test) @ project ---
Downloading: http://repo.maven.apache.org/maven2/org/apache/maven/surefire/surefire-testng/2.14/surefire-testng-2.14.pom
Downloaded: http://repo.maven.apache.org/maven2/org/apache/maven/surefire/surefire-testng/2.14/surefire-testng-2.14.pom (4 KB at 16.1 KB/sec)
Downloading: http://repo.maven.apache.org/maven2/org/apache/maven/surefire/common-java5/2.14/common-java5-2.14.pom
Downloaded: http://repo.maven.apache.org/maven2/org/apache/maven/surefire/common-java5/2.14/common-java5-2.14.pom (2 KB at 36.6 KB/sec)
Downloading: http://repo.maven.apache.org/maven2/org/apache/maven/surefire/surefire-testng/2.14/surefire-testng-2.14.jar
Downloading: http://repo.maven.apache.org/maven2/org/apache/maven/surefire/common-java5/2.14/common-java5-2.14.jar
Downloaded: http://repo.maven.apache.org/maven2/org/apache/maven/surefire/common-java5/2.14/common-java5-2.14.jar (55 KB at 588.4 KB/sec)
Downloaded: http://repo.maven.apache.org/maven2/org/apache/maven/surefire/surefire-testng/2.14/surefire-testng-2.14.jar (33 KB at 206.7 KB/sec)
Downloading: http://repo.maven.apache.org/maven2/org/apache/maven/surefire/surefire-testng-utils/2.14/surefire-testng-utils-2.14.jar
Downloaded: http://repo.maven.apache.org/maven2/org/apache/maven/surefire/surefire-testng-utils/2.14/surefire-testng-utils-2.14.jar (29 KB at 537.0 KB/sec)
Downloading: http://repo.maven.apache.org/maven2/org/apache/maven/surefire/surefire-grouper/2.14/surefire-grouper-2.14.jar
Downloaded: http://repo.maven.apache.org/maven2/org/apache/maven/surefire/surefire-grouper/2.14/surefire-grouper-2.14.jar (37 KB at 636.5 KB/sec)

-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running TestSuite
Configuring TestNG with: TestNGMapConfigurator
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.723 sec

Results :

Tests run: 0, Failures: 0, Errors: 0, Skipped: 0

Just because swift-service uses TestNG under surefire, it shouldn't export that configuration to downstream projects.

I tried adding an exclusion for surefire-testng in the dependency declaration for swift-service but that didn't help. Will investigate further.

swift-generator doesn't auto generate builders

The swift-generator by default generates immutable objects. It would be nice to also auto generate builder files for each generated thrift object.

We can use the "-generate_beans" flag in the mean time, but it would be nice to keep these objects as immutable and have a way to effectively construct them.

Thanks

Add Server Side stats and expose them via jmx

There are many server side metrics which can be potentially used to debug issues and also fine tune the server configuration. For example, metrics like
*call queue length
*wait time in queue
*num worker threads busy/idle

Would be useful to identify the bottlenecks on the server side.

Also, AFAIK, Guice is the recommended way of capturing the stats. Apart from Guice, there should be easier via to capture the stats and expose them via JMX.

Cannot use guice to inject two ThriftServers

Because ThriftServer and ThriftServiceProcessor are bound as singletons, it is difficult to create two swift servers (listening on two different ports) via guice.

We should either come up with some module changes that make this feasible, or else add instructions recommending child injectors for this.

Reject requests if the Memory used by requests is too high.

The current swift server does not have throttling of requests based on the amount of space consumed by the currently ongoing requests. We should be able to provide a limit for the amount of space that can be occupied by the currently ongoing requests. In that case, if the server can reject the client request, we can catch it as a TTransportException on the client and retry with timeouts.

Need to handle the case where a sync call is made on the channel's I/O thread

Because connecting returns a future, a common pattern you might try to use is to add a future listener waiting for the successful connect, and in that listener make a thrift call.

However, if you make a blocking thrift call, you will deadlock the netty I/O thread.

We should check this before starting blocking thrift calls, and throw an exception in this case.

Avoid unnecessary memcopy during during Async Client calls

It looks like the async call has majorly 3 steps:

  1. Serialize the method+data into the outputTransport
  2. Copy the data from outputTransport into a new ChannelBuffer
  3. Enqueue the request to nio-client threadpool

By looking at the SocketSendBufferPool class, acquire(), seems like it copies the ChannerBuffer into a “pooled” DirectBuffer if the size is less than 64KB. I was curious to know if we could directly copy the outputTransport data in step 2 to DirectBuffer(we already know the size), or create a new transport on every call to avoid this extra copy??

generator does not support unions

Try comping the hive metastore thrift api:

union ColumnStatisticsData {
1: BooleanColumnStatsData booleanStats,
2: LongColumnStatsData longStats,
3: DoubleColumnStatsData doubleStats,
4: StringColumnStatsData stringStats,
5: BinaryColumnStatsData binaryStats
}

does not generate any code.

swift-generator needs to generate equals() and hashcode for structs

Without this, every time I re-generate the code for a given IDL, I have to manually go and resolve all the conflicts in my immutable types because I added equals() and hashcode() to some of the classes, but the generator overwrites my change.

Specifically I am talking in the context of swift-scribe in swift-fbcode. The LogEntry object had equals() and hashcode(), added by me.

Add checks to verify that we don't have multiple ways to inject field values

As of a few days ago, if you add a @ThriftField-annotated public field, a @ThriftConstructor constructor with a @ThriftField-annotated parameter for setting that same field, and a @ThriftField-annotated setter method for setting that field, swift will call ALL of them when reading the type off the wire (assuming that field is read from the wire).

We should add checks to the metadata builders that there is only one annotated way to set each field. It's still ok for a class to have a two ways to actually set the method, as long as they aren't annotated.

Swift generator Constants file confict if more than one file in the same namespace defines a contant

ava -jar /tmp/swift-generator-cli-0.10.0-standalone.jar common/smc/if/Smc2.thrift

Smc2.thrift defines a constant but itself imports ServiceManager.thrift. ServiceManager.thrift defines more constants. The generator creates Constants.java for Smc2.thrift and ServiceManager.thrift separately. It requires a developer to manually rename one of the Constants file to a different name, otherwise the build will fail with two classes having the same name.

ThriftServiceProcessor says it isn't production ready

The commend at the top of ThriftServiceProcessor says "This should only be considered an example, and is not production ready. For example, this class makes assumptions about the thrift id of method parameters, and does not support Thrift exceptions properly." Per David Phillips it's used in production. So, the comment should be updated.

Make swift-codec compatible with lombok beans

lombok lets you auto-generate setters & getters for beans. The current @ThriftField annotation can be attached to either an accessor method or a public variable.

It would be nice if we could attach this to the underlying private member of the bean. This would also make the Immutable object instances have lesser code

Swift does not respect optional keyword, or default values for optionals

In thrift IDL, the "optional" keyword applied to a struct field means that the writer will not serialize the optional value if it is not set, and the reader side will fill in the field with the default value declared in the IDL, or the default for the type if there was no declared default. The reader will have a way to tell if the writer set the field or not.

Currently, swift lets you set a field to null, and when that field is null, the writer will not write the value. The reader will see a null when reading the type. But this leaves a couple of very minor gaps:

  • for default values, you can just add code to the constructor or the class to setup the default values, but...
  • if you were to add code to setup default values, then it is impossible to tell if the field was set directly or not, making it impossible to tell whether the field should be serialized when sending, and impossible to tell on the receiving end whether the field was set to the default by the sender, or not sent at all

Someday it might be nice to add an Optional type, that acts like guava Optional except that it has a "orDefault()" method that would return the set value or the default. The sender could then not send if isPresent()==false, and the receiver could use orDefault() to get the effective value, while using isPresent() to determine whether the value was received from the sender or not.

Publish jars to be usable outside of Facebook

I would be interested in trying out Thrift IDL parser, but the current maven build fails due to missing parent pom version (version 1 is available, mainline refers to 3-SNAPSHOT).
Ideally I could just use a released version.

Swift generator generates Constants file that does not compile

java -jar /tmp/swift-generator-cli-0.10.0-standalone.jar common/smc/if/ServiceManager.thrift

generates the following line

public static final int kSmcProxyDefaultPort = 9099L;

which failed to compile since the compiler complains about

[ERROR] /Users/lif/swift-fbcode/swift-smc/src/main/java/com/facebook/swift/services/Constants.java:[58,52] possible loss of precision

This is because we are assigning a long to an int.

ThriftClientManagerConfig needs to provide a way to configure the worker thread count in Netty

We have a way to configure the worker thread count for Thrift servers, but not for the client. ThriftClientManagerConfig only allows one to configure the socks proxy address and ThriftClientModule will use the NettyClientConfig object with most default options. This lead to the creation of 64 threads for PTail, which makes less than 10 thrift calls per second.

We need a way to reduce the number of worker thread counts in swift.

Upload nifty 0.15.0 SNAPSHOT to sonatype

When I try to build a fresh version of the maven project I get this error:

ailed to execute goal on project swift-service: Could not resolve dependencies for project com.facebook.swift:swift-service:jar:0.15.0-SNAPSHOT: The following artifacts could not be resolved: com.facebook.nifty:nifty-client:jar:0.15.0-SNAPSHOT, com.facebook.nifty:nifty-core:jar:0.15.0-SNAPSHOT: Failure to find com.facebook.nifty:nifty-client:jar:0.15.0-SNAPSHOT in https://oss.sonatype.org/content/repositories/snapshots was cached in the local repository, resolution will not be reattempted until the update interval of sonatype-nexus-snapshots has elapsed or updates are forced -> [Help 1]

When I changed my pom file to use 0.14.0 (which is on sonatype) I no longer have dependency issues.

ThriftServerModule need to provide a bindWorkerExecutor() method with a Provider class

bindWorkerExecutor() in ThriftServerModule only has three choices:

  1. bind to an executor type;
  2. bind to an executor instance;
  3. bind to a Provider instance

However, I need to have a flavor that binds to a Provider type. This is because 3. exposes the constructor for the Provider, which creates problems if the Provider needs dependencies. In particular, if I need to export the queue size as a stats value, I need dependencies on the stats library which is itself configured with Guice. Such a Provider cannot have its dependency satisfied in configure().

Java 8 is not happy with swift 0.10.0

Seeing this stack trace when I tried to run PTail, which has a nifty server that uses swift:

java.lang.ClassCastException: java.lang.Long cannot be cast to com.facebook.swift.services.Property
at $wift.com.facebook.swift.services.PropertyCodec.write(Unknown Source)
at com.facebook.swift.codec.internal.TProtocolWriter.writeMap(TProtocolWriter.java:299)
at com.facebook.swift.codec.internal.builtin.MapThriftCodec.write(MapThriftCodec.java:66)
at com.facebook.swift.codec.internal.builtin.MapThriftCodec.write(MapThriftCodec.java:28)
at com.facebook.swift.codec.internal.TProtocolWriter.writeField(TProtocolWriter.java:65)
at com.facebook.swift.service.ThriftMethodProcessor.writeResponse(ThriftMethodProcessor.java:319)
at com.facebook.swift.service.ThriftMethodProcessor.access$300(ThriftMethodProcessor.java:57)
at com.facebook.swift.service.ThriftMethodProcessor$1.onSuccess(ThriftMethodProcessor.java:164)
at com.google.common.util.concurrent.Futures$4.run(Futures.java:1169)
at com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:297)
at com.google.common.util.concurrent.Futures$ImmediateFuture.addListener(Futures.java:100)
at com.google.common.util.concurrent.Futures.addCallback(Futures.java:1172)
at com.google.common.util.concurrent.Futures.addCallback(Futures.java:1108)
at com.facebook.swift.service.ThriftMethodProcessor.process(ThriftMethodProcessor.java:151)
at com.facebook.swift.service.ThriftServiceProcessor.process(ThriftServiceProcessor.java:126)
at com.facebook.nifty.core.NiftyDispatcher$1.run(NiftyDispatcher.java:137)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

This shows up when the dev servers start to run Java 8 by default.

Need method to add 3rd party types to catalog for swift2thrift

I'd like make it easy to taken existing service interfaces (dealing with some third party beans types), and make them available as a swift service and generate thrift clients via swift2thrift.

A number of serialization frameworks provide the ability to serialize types without adding requiring ownership of the source code for that types (e.g. Jackson support serialization of beans) -- so, I'm working on a method to register types prior to:

  • running thrift2swift
  • creating a swift service

I'm looking at providing an alternate SwiftStructMetaDataBuilder to do this. It will:

  • work for bean-style classes
  • work for classes with public fields
  • work for scala-style fields
  • enforce a consistent (alphabetical) ID ordering of these
  • warn about future-proofing (since this classes are unannotated thrift's ID bases future proofing goes out of the window)

Does this look the reasonable approach (adding a SwiftStructMetaDataBuilder, using it to generate a ThriftType and registering the type with the catalog)?

Can we make the immutable structs generated by swift-generator a bit Jackson friendly?

By default, the structs generated by the swift generator does not have

@JsonProperty(value = "<field_name>")

in the constructor for each field. It seems this annotation is needed in order for Jackson to read the struct from json.

For example, I have the following class generated

package com.facebook.calligraphus.bucketing.shardmanager;

/**
*/

import com.facebook.swift.codec.ThriftConstructor;
import com.facebook.swift.codec.ThriftField;
import com.facebook.swift.codec.ThriftStruct;
import com.fasterxml.jackson.annotation.JsonProperty;

import java.util.Map;

import static com.google.common.base.Objects.toStringHelper;

@ThriftStruct("com.facebook.swift.shardmanager.SmcServiceTierScopesProp")
public class SmcServiceTierScopesProp
{
@ThriftConstructor
public SmcServiceTierScopesProp(
@JsonProperty(value = "scopePrefix") <-- need this line
@ThriftField(value=1, name="scopePrefix") final Map<String, String> scopePrefix
) {
this.scopePrefix = scopePrefix;
}

private final Map<String, String> scopePrefix;

@ThriftField(value=1, name="scopePrefix")
public Map<String, String> getScopePrefix() { return scopePrefix; }

@OverRide
public String toString()
{
return toStringHelper(this)
.add("scopePrefix", scopePrefix)
.toString();
}
}

and I have the following json

String prefixValue = "  {\n" +
  "    \"scopePrefix\" : \n" +
  "      {\n" +
  "        \"calligraphustest-frc1-12\" : \"cluster:frc1.12:\",\n" +
  "        \"calligraphustest-prn1-12\" : \"cluster:prn1.12:\"\n" +
  "      }\n" +
  "    \n" +
  "  }";

  prop = MAPPER.readValue(
    prefixValue,
    SmcServiceTierScopesProp.class);
  return prop.getScopePrefix();

This code throws in the readValue() line if the annotation is not there, because Jackson does not know how to construct the object without the annotation.

Any better suggestions here?

Shade ASM dependency

ASM is a common dependency problem because they make backwards incompatible changes across releases. Swift (and generally anything that uses ASM) should include it as a shaded dependency.

scala collections support?

Not sure this is the right place- can't find a swift mailing list.

Does swift directly support both java and scala collections?

I'm hoping to be able to take a set of abstract scala traits (dealing with existing data-types that are already easily JSON-serialiable), and expose them as RPC APIs to clients in various languages. I've read that thrift-swift will let me generate .idl files from existing interfaces. Does this include Scala, or just Java.
On the server I'm hoping I can straightforwardly directly export a Thrift server for these with Finagle. 

Am I on the right track? (Can I expect to export thrift .idls from Scala code, and can I easily implement my own server to match these IDL-generated clients?)

I've tried running:

MY_CLASSES=$HOME/ExampleServiceMvn/target/ExampleService-1.0-SNAPSHOT.jar  # just an example
SCALA_CLASSES=$HOME/.m2/repository/org/scala-lang/scala-library/2.10.2/scala-library-2.10.2.jar
java -cp target/swift2thrift-generator-cli-0.15.0-SNAPSHOT-standalone.jar:$MY_CLASSES:$SCALA_CLASSES com.facebook.swift.generator.swift2thrift.Main -package com.example ExampleService -map ExampleService path/to/base.thrift -namespace py mycomany.thrift -namespace java mycompany.thrift -namespace cpp mycompany

This works fine for the scala classes that only with Java collections, but if my service interface deals with scala collections, I get:

Exception in thread "main" java.lang.IllegalArgumentException: Type can not be coerced to a Thrift type: scala.collection.immutable.List<java.lang.String>
    at com.facebook.swift.codec.metadata.ThriftCatalog.getThriftType(ThriftCatalog.java:291)
    at com.facebook.swift.service.metadata.ThriftMethodMetadata.<init>(ThriftMethodMetadata.java:90)
    at com.facebook.swift.service.metadata.ThriftServiceMetadata.<init>(ThriftServiceMetadata.java:73)
    at com.facebook.swift.generator.swift2thrift.Swift2ThriftGenerator.convertToThrift(Swift2ThriftGenerator.java:432)
    at com.facebook.swift.generator.swift2thrift.Swift2ThriftGenerator.<init>(Swift2ThriftGenerator.java:112)

I'm happy to add scala collection support to swift2thrift if that makes sense.

Also, the above is using using the https://github.com/facebook/swift/ checkout

What the relationship between this and finagle/finagle-swift in https://github.com/twitter/finagle?

And how can I compile the git checkout? Tried the following:

# Succeeds, but no jars
cd finagle/doc/src/sphinx/code/quickstart  && ./sbt compile
cd finagle/doc/src/sphinx/code/quickstart  && ./sbt package

# [error] (finagle-ostrich4/*:update) sbt.ResolveException: unresolved dependency: com.twitter#ostrich_2.10;9.6.1: not found
cd finagle; ./sbt package

# [error] Not a valid project ID: finagle-swift (similar: finagle-thrift, finagle-test, finagle-stats)
cd finagle; ./sbt 'project finagle-swift' compile

#[ERROR]     Non-resolvable parent POM: Could not find artifact com.twitter:scala-parent-2104_2.10:pom:0.1.14 in central (http://repo.maven.apache.org/maven2) and 'parent.relativePath' points at wrong local POM @ line 8, column 11 -> [Help 2]
cd finagle/finagle-swift ; mvn compile

# Produces ./finagle-thrift/target/scala-2.10/finagle-thrift_2.10-6.22.0.jar
# but doesn't include thrift-swift
cd finagle; ./sbt 'project finagle-thrift' package

-- thanks

  • Stuart

Check that types annotated with @ThriftStruct and @ThriftUnion are final before allowing them to be used as fields in other thrift types, or as parameters or return values

People are starting to make use of the fact that swift allows them to build thrift types with inheritance, and this is great. (We'll probably add this to thrift IDL, too.)

But it is important to realize that thrift will not encode fields from derived types, so the types of the instances you pass around need to be final. We should probably enforce that in ThriftStructMetadataBuilder.

Clients and codecs should be validated transitively at injector creation

When binding a client or codec, Swift should validate the client or codec and all of its dependent codecs when the injector is created. Currently, this seems to happen lazily at runtime, so an infrequently called method or used field won't be detected until it is already in production (assuming it is not explicitly covered by tests).

This will make it much easier to get full test coverage of all structs and catch problems like missing the new requirement that classes be final. It should be enough for a test to simply bind the client.

[wishlist] Iterable thrift structures

Currently the way we can have iterable thrift structures is by having a List of items. We can access the items of the list only after we have the entire list. Also, we need to de-serialize all the elements in order to read even the very first element. This might add unnecessary memory pressure on the system.

Container data structures backed by byte buffers.

In scenarios where we have a list of containers, where each container holds a byte buffer. The byte buffers of individual containers can be backed by a single byte array. This would significantly cut down small object creation in large throughput systems by almost a factor of 2.

Missing pom dependencies. Can't use swift2thrift-generator-cli

git clone https://github.com/facebook/swift
cd swift/
mvn compile

yields

[INFO] ------------------------------------------------------------------------
[INFO] Building swift-service 0.15.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[WARNING] The POM for com.facebook.nifty:nifty-client:jar:0.15.0-SNAPSHOT is missing, no dependency information available
[WARNING] The POM for com.facebook.nifty:nifty-core:jar:0.15.0-SNAPSHOT is missing, no dependency information available

In particular, what's the most straightforward way to get swift2thrift-generator-cli working? Do I need to add nifty-core.jar to my classpath, or should it be listed as a maven depenedency?

Detect when a server handler method throws an exception annotated with @ThriftStruct that is not part of the method's interface

In order for a custom exception to be serialized, it must be both annotated with @ThriftStruct, and also be mentioned (with an id) in the @ThriftMethod annotations for the methods that throw it. The second part is required because the exception will be serialized into the result field based on that id.

If the server handler throws an exception annotated with @ThriftStruct but not mentioned in the @ThriftMethod annotation, we'll serialize a TApplicationException instead. We should probably log a warning about this, or mention this in the exception message, since it was probably the server writer's intent that the custom exception be serialized.

Want method to specific service methods via interfaces instead of classes

Sometimes a single service object may implement multiple service APIs for different consumers (e.g. web client vs. internal client).

@ThriftService
public interface MyWebClientService {
    @ThriftMethod
    public User getUser(User id)

    @ThriftMethod
    public LoginToken login(String user, String password)
}

@ThriftService
public interface MyInternalService {
    @ThriftMethod
    public User getUser(User id)

    @ThriftMethod
    public SecureData getSecureData()
}

public class MyServiceImpl implements MyInternalService, MyUserService {
    public User getUser(User id) { .... }
    public LoginToken login(String user, String password) { ... }
    public User getUser(User id) { ... }
    public SecureData getSecureData() { ... }
}

Would like to export different API views of MyServiceImpl implements internally and to web clients.

Is this already possible?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.