spotify / apollo

Java libraries for writing composable microservices

Apollo

Status: Archived

⚠️ Apollo is heavily used within Spotify, however, most of its development has recently been done internally leveraging Apollo's module system. Because of this, and the fact that Apollo has very little (if any) use outside Spotify we want to signal this current state to the community by putting the project in archive mode. This means this project will no longer have new features, bug fixes or accept PRs for new features. Apollo development will continue internally in Spotify.

Apollo is a set of Java libraries that we use at Spotify when writing microservices. Apollo includes modules such as an HTTP server and a URI routing system, making it trivial to implement restful API services.

Apollo has been used in production at Spotify for a long time. As a part of the work to release version 1.0.0 we moved the development of Apollo into the open.

There are two main libraries in Apollo:

• apollo-api
• apollo-core

Apollo API

The apollo-api library is the Apollo library you are most likely to interact with. It gives you the tools you need to define your service routes and your request/reply handlers.

Here, for example, we define that our service will respond to a GET request on the path / with the string "hello world":

public static void init(Environment environment) {
  environment.routingEngine()
      .registerAutoRoute(Route.sync("GET", "/", requestContext -> "hello world"));
}

Note that, for an Apollo-based service, you can see the routes defined for a service by querying /_meta/0/endpoints.

The apollo-api library provides several ways to help you define your request/reply handlers. You can specify how responses should be serialized (such as JSON). Read more about this library in the Apollo API Readme.

Apollo Core

The apollo-core library manages the lifecycle (loading, starting, and stopping) of your service. You do not usually need to interact directly with apollo-core; think of it merely as "plumbing". For more information about this library, see the Apollo Core Readme.

Apollo Test

In addition to the two main Apollo libraries listed above, to help you write tests for your service we have an additional library called apollo-test. It has helpers to set up a service for testing, and to mock outgoing request responses.

Links

Introduction Website
JavaDocs
Maven site

Diagrams

Code of conduct

This project adheres to the Open Code of Conduct. By participating, you are expected to honor this code.

apollo's Issues

Security: is possible to add role to Route URI?

Hi,
I'd like to 'authorize' a route Uri using something like Security Roles.
I mean something like the code below (using annotation for example):
`
@RolesAllowed("list-of-roles")
Route.async("GET", "/services/configurations", getServices).withDocString("Service configurations", "")

@RolesAllowed("list-of-other-roles")
Route.async("GET", "/services/performance", getPerformance).withDocString("Service performance", "")

...
`
Is this possible?

File Upload

Hi,
is there a way to implement file upload using Apollo Rest API?
What is the correct approach to do it?

Problems building examples

When running mvn package inside the examples I get the following error message:

Stefans-iMac:spotify-api-example stefan$ mvn package
[INFO] Scanning for projects...
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[ERROR] Non-resolvable import POM: Could not find artifact com.spotify:apollo-bom:pom:2.0.0-SNAPSHOT @ line 14, column 25
[ERROR] 'dependencies.dependency.version' for com.spotify:apollo-http-service:jar is missing. @ line 25, column 21
[ERROR] 'dependencies.dependency.version' for com.spotify:apollo-extra:jar is missing. @ line 30, column 21
[ERROR] 'dependencies.dependency.version' for ch.qos.logback:logback-classic:jar is missing. @ line 35, column 21
 @ 
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]   
[ERROR]   The project com.spotify:spotify-api-example-service:0.0.1-SNAPSHOT (/Users/stefan/Developer/apollo/examples/spotify-api-example/pom.xml) has 4 errors
[ERROR]     Non-resolvable import POM: Could not find artifact com.spotify:apollo-bom:pom:2.0.0-SNAPSHOT @ line 14, column 25 -> [Help 2]
[ERROR]     'dependencies.dependency.version' for com.spotify:apollo-http-service:jar is missing. @ line 25, column 21
[ERROR]     'dependencies.dependency.version' for com.spotify:apollo-extra:jar is missing. @ line 30, column 21
[ERROR]     'dependencies.dependency.version' for ch.qos.logback:logback-classic:jar is missing. @ line 35, column 21
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
[ERROR] [Help 2] http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException

Admittedly I'm almost a complete newbie to Maven, so most likely this is minor issue. It would be nice if the examples ran without any further tweaking, though.

I ran from a clean setup of the JDK and Maven.

Ability to access network layer information in HTTP request context

Currently, there is no way to access network and transport layer information such as client/server IPs and ports in HTTP request context. In some cases, this information is necessary for example for GeoIP checks or whitelisting. Having such ability would be nice.

Remove AP stuff?

Should this file be in here when apollos is open sourced?

https://github.com/spotify/apollo/blob/master/apollo-api-impl/src/main/java/com/spotify/apollo/dispatch/EndpointInvocationHandler.java

How to get remote client IP for a request?

I want to get from a RequestContext (or perhaps some other class) the client's IP address. How can I do that? RequestMetadata from RequestContext always seems to have an Optional.empty for HostAndPort. https://github.com/spotify/apollo/blob/master/apollo-api-impl/src/main/java/com/spotify/apollo/request/OngoingRequest.java#L96

apollo-core looking for environment variables in the SPOTIFY_X_Y namespace.

While it works perfectly for spotify internal services mandating that for other peoples services feels a bit wrong and is likely a source for confusion (ehh, why is this called spotify, huh?). Perhaps default to APOLLO_X_Y or $SERVICENAME_X_Y?

Referenced here:
https://github.com/spotify/apollo/blob/master/apollo-core/README.md

Implemented here:
https://github.com/spotify/apollo/blob/master/apollo-core/src/main/java/com/spotify/apollo/core/ServiceImpl.java#L421

How to configure the ListeningExecutorService

https://github.com/spotify/apollo/tree/master/apollo-core#scoped-executors

Is it possible to configure the number of threads used to initialize the ListeningExecutorService that is exposed by the Service.Instance object?

Change URI of Request

When requesting a scoped client, it would be nice if headers were copied over. This would simplify making "pass through" requests.

Unclear relationship between ApolloEnvironmentModule and apollo-meta

These are some observations I have after the changes made in #64

While ApolloEnvironmentModule gets a MetaInfoTracker injected, it is still responsible for wiring up the MetaApplication and ApplicationOrMetaRouter into the final RequestHandler. This seems like a spread out responsibility. Specially since 3rd party implementations of MetaInfoTracker would not be able to affect any of the other details of the meta api. So effectively leaving them to just implement a different store mechanism for the meta information.

How about this

• Move the wiring of both MetaApplication and ApplicationOrMetaRouter into apollo-meta, injected as a RequestRunnableFactoryDecorator.
• Make MetaInfoTracker an optional dependency of ApolloEnvironmentModule so that one does not always have to set up metadata collection when using it. If doing the previous change, ApolloEnvironmentModule would only need to call metaInfoTracker.gatherEndpoints(applicationRouter.getRuleTargets()) if the tracker is present.

Expose ExecutorService's ThreadPoolExecutor for metrics collection

Or an abstraction that enables access to the thread pool usage metrics like number of active threads, current pool size, max pool size, task count...

Right now there is no way to obtain those values afaik:
https://github.com/spotify/apollo/blob/master/apollo-core/src/main/java/com/spotify/apollo/core/ServiceImpl.java#L259

MetaGatherer.EndpointGatherer tracks single content type

This is broken in a few ways:

• the field never gets set
• an endpoint may return different content types for different requests

Server Side Event for server-side push

Hi,
I'd like to understand and imlement SSE using Apollo.
What I should do to create a notification service that return a message to the client if something change on server side?
It is just like a Route.async operation?

Examples fail to start with -Dhttp.server.port=8080

Starting up on windows 10, with the following command (stated in the docs):
java -jar target/java-exam.jar -Dhttp.server.port=8080

Gives the following warning:
16:59:16.373 [main] WARN c.s.a.http.server.HttpServerProvider - Not loading http server - enable with: http.server.port = 8080

Running just: java -jar target/java-exam.jar works (I have the port configured on the .conf file).

Maybe this is not actually a bug, but the docs should be updated then.

Thanks.

Specify Request.uri more precisely

The current javadoc reads:

* The uri of the request message.
* Uri query parameters are available via {@link #parameter(String)} and {@link #parameters()}.
* Uri pathArgs are available in {@link RequestContext}.

Some details that are unspecified:

• Does the uri contain the scheme of the incoming request?
• Does it contain the authority?
• How does it relate to Route.uri?
• What are the differences between an incoming Request and one created for an outgoing Client call?

Simplify external testing by providing a Client that can send HTTP requests

Currently, if you want to do an integration test of a running, complete service (i.e., not via the ServiceHelper, which doesn't open any sockets), you need to send raw HTTP messages via your own HTTP client and interpret the results manually. It would probably be cleaner to write test code if there was a way to do something along the lines of

import com.spotify.apollo.Client;

class MyIntegrationTest {
  // - some things omitted

  Client client;

  @Before
  public void setup() {
     client = Clients.open(HostAndPort.of("localhost", servicePort));
  }

  @Test
  public void shouldBlah() {
    CompletionStage<Response<ByteString>> responseStage = client.send(Request.forUri("/floop"));
   // ... do something with the response
  }

Service.Instance Scoped executors has no thread pool size limit

instance.getExecutorService() uses Executors.newCachedThreadPool which has no thread pool size limit

see http://stackoverflow.com/questions/1800317/impossible-to-make-a-cached-thread-pool-with-a-size-limit

Confusing ClientId comparator for simple use cases

I'm creating an Apollo Service for using the client only. It looks like this:

    final Service cliService = Services.usingName("styx-cli")
        .withEnvVarPrefix(ENV_VAR_PREFIX)
        .withModule(ApolloEnvironmentModule.create((a,b) -> 0)) // <-- this
        .withModule(HttpClientModule.create())
        .build();

I only have one explicit client module mixed in, but I'm still forced to supply a comparator for client implementations. It would be convenient to have a constructor like ApolloEnvironmentModule.createDefault() that would not specify any particular order order for the client.

Relates to #64

Rename statusCode().statusCode()

from @liljencrantz

could some/both of Response.statusCode() and StatusType.statusCode() be renamed?

Response.status() and StatusType.code()?

Unit Tests for improved test coverage

Hi Spotfy team!

I'm currently working at devfactory. We are looking for open source projects to make them more reliable. Will it be helpful if we write some unit tests for certain modules to improve overall tested code coverage?

I'm looking forward to hearing from you.
Kind regards,

Add Middleware to a set o routes

Hi,
Is it possible to add a Middleware to a set of routes without registering the middleware in every route?

Don't export problematic dependencies

Libraries like Guava and Jackson are widely used and tend to come in incompatible versions, leading to dependency hell. We should avoid exposing them in APIs and relocate them to internal classes when they are used internally.

Request#header(String) should be case insensitive for HTTP requests

See http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html
From 4.2 Message Headers: "Field names are case-insensitive."

This will otherwise cause problems when interacting with proxies or clients that perform pre-emptive all-to-lowercase/uppercase example here before the request hits the Apollo-based service.

What about security?

Namely, Authentication and Authorisation?

apollo-bom doesn't use scopes in dependencyManagement

I noticed in a project I am working on that a dependency on apollo-test:1.1.0:test ends up dragging in com.google.auto.value:auto-value:1.1. I expected the latter to have <scope>provided</scope> in apollo-test, since AFAIK code generated by auto-value has no dependencies on auto-value (and scope=provided is what the auto-value docs recommend.

But I noticed that in the apollo-bom, none of the modules under the comment for "provided scope" actually have scope=provided. Is that an oversight? Or a limitation of the bom concept?

How to get the Request protocol from Request.uri()?

When I made a request and try to capture the Request protocol, I can't get it from Request.url(). How to do get it?

According to the W3 doc, it should have it from the Reqest-URI
https://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html

Example:
GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1

How do I get the "HTTP/1.1"?

Java 9 Illegal Access Warnings

Users running styx cli (that depends on Apollo) on Java 9 get this

Bartoszs-MacBook-Pro:~$ styx e gabo-anonym-low-priority events.Nlu-Search-Api.NaturalLanguageQuery.gcs 2018-02-06T07
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.google.inject.internal.cglib.core.$ReflectUtils$2 (file:/usr/local/Cellar/styx-cli/1.0.95/libexec/styx-cli-1.0.95.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
WARNING: Please consider reporting this to the maintainers of com.google.inject.internal.cglib.core.$ReflectUtils$2
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

We could of course work around by enforcing Java 8, but this seems to have a simple version bump fix that's coming up, in google/guice#1085.

Related: spotify/styx#366, #242

Add circuit breaker support

See for instance http://martinfowler.com/bliki/CircuitBreaker.html.

The main benefits we're looking for here:

1. In the case of a slow dependency, we've already got TTLs that help set a maximum latency added to requests (that will be roughly the TTL), but essentially all requests will hit that maximum latency. With a circuit breaker that treats timeouts as failures, we can get reduced latency while it is tripped.
2. Allowing failing services breathing room to recover.

Change coverage reporting to codecov.io

Opening this up for discussion. I recently tried out https://codecov.io/ on a project and was impressed by their feedback. Some benefits I see over the coveralls integration

• Metrics posted as a comment in the PR, with +/- on coverage
• Their awesome browser extension which annotate the PR diff view with coverage/missed per line

NPE in RuleRouter class

This line throws a NullPointerException if the decoding of the segment fails:

https://github.com/spotify/apollo/blob/master/apollo-route/src/main/java/com/spotify/apollo/route/RuleRouter.java#L83

Can this be handled in a better way, perhaps by returning a 400 response?

Example stack trace:

2016-05-13T13:17:09.729+00:00 4855ade21a5b playlist-proxy[8]: Exception when handling request
2016-05-13T13:17:09.729+00:00 4855ade21a5b playlist-proxy[8]: java.lang.NullPointerException: null
2016-05-13T13:17:09.729+00:00 4855ade21a5b playlist-proxy[8]: at com.spotify.apollo.route.RuleRouter.readParameterValue(RuleRouter.java:83)
2016-05-13T13:17:09.729+00:00 4855ade21a5b playlist-proxy[8]: at com.spotify.apollo.route.RuleRouter.match(RuleRouter.java:74)
2016-05-13T13:17:09.729+00:00 4855ade21a5b playlist-proxy[8]: at com.spotify.apollo.meta.ApplicationOrMetaRouter.match(ApplicationOrMetaRouter.java:56)
2016-05-13T13:17:09.729+00:00 4855ade21a5b playlist-proxy[8]: at com.spotify.apollo.request.RequestRunnableImpl.matchAndRun(RequestRunnableImpl.java:83)
2016-05-13T13:17:09.729+00:00 4855ade21a5b playlist-proxy[8]: at com.spotify.apollo.request.RequestRunnableImpl.run(RequestRunnableImpl.java:70)
2016-05-13T13:17:09.729+00:00 4855ade21a5b playlist-proxy[8]: at com.spotify.apollo.request.RequestHandlerImpl.handle(RequestHandlerImpl.java:65)
2016-05-13T13:17:09.729+00:00 4855ade21a5b playlist-proxy[8]: at com.spotify.apollo.hermes.server.HermesRequestHandler.handleRequest(HermesRequestHandler.java:31)
2016-05-13T13:17:09.729+00:00 4855ade21a5b playlist-proxy[8]: at com.spotify.hermes.service.impl.AbstractServiceRunnable.doRun(AbstractServiceRunnable.java:175)
2016-05-13T13:17:09.729+00:00 4855ade21a5b playlist-proxy[8]: at com.spotify.hermes.service.impl.AbstractServiceRunnable.run(AbstractServiceRunnable.java:133)
2016-05-13T13:17:09.729+00:00 4855ade21a5b playlist-proxy[8]: at com.spotify.jsr166.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1398)
2016-05-13T13:17:09.729+00:00 4855ade21a5b playlist-proxy[8]: at com.spotify.jsr166.ForkJoinTask.doExec(ForkJoinTask.java:260)
2016-05-13T13:17:09.729+00:00 4855ade21a5b playlist-proxy[8]: at com.spotify.jsr166.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:858)
2016-05-13T13:17:09.729+00:00 4855ade21a5b playlist-proxy[8]: at com.spotify.jsr166.ForkJoinPool.scan(ForkJoinPool.java:1687)
2016-05-13T13:17:09.729+00:00 4855ade21a5b playlist-proxy[8]: at com.spotify.jsr166.ForkJoinPool.runWorker(ForkJoinPool.java:1642)
2016-05-13T13:17:09.729+00:00 4855ade21a5b playlist-proxy[8]: at com.spotify.jsr166.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:109)

Add support for WebSockets

We are soon going to build systems that have a need for real time updates from the servers. Exposing nettys built in support for WebSockets in our routing engine would help us tremendously with that task.

Incorrect request logging on timeout

The following may happen:

1. A request arrives, and processing starts
2. The TTL expires, and a 500 Timeout response is sent
3. Processing finishes successfully, and the request is logged as 200 OK (or something else)

Unable to build project

I'd like to submit a patch but I am unable to build the project in order to test it.
I've cloned the project and run mvn package, but I get this:

16:13 $ mvn package
[INFO] Scanning for projects...
[WARNING] 
[WARNING] Some problems were encountered while building the effective model for com.spotify:apollo-bom:pom:2.0.0-SNAPSHOT
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-surefire-plugin is missing. @ com.spotify:apollo-parent:2.0.0-SNAPSHOT, /Users/eduardo/Development/apollo/pom.xml, line 123, column 21
[WARNING] 
[WARNING] Some problems were encountered while building the effective model for com.spotify:apollo-core:jar:2.0.0-SNAPSHOT
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-surefire-plugin is missing. @ com.spotify:apollo-parent:2.0.0-SNAPSHOT, /Users/eduardo/Development/apollo/pom.xml, line 123, column 21
[WARNING] 
[WARNING] Some problems were encountered while building the effective model for com.spotify:apollo-api:jar:2.0.0-SNAPSHOT
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-surefire-plugin is missing. @ com.spotify:apollo-api:[unknown-version], /Users/eduardo/Development/apollo/apollo-api/pom.xml, line 81, column 21
[WARNING] 
[WARNING] Some problems were encountered while building the effective model for com.spotify:apollo-api-impl:jar:2.0.0-SNAPSHOT
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-surefire-plugin is missing. @ com.spotify:apollo-parent:2.0.0-SNAPSHOT, /Users/eduardo/Development/apollo/pom.xml, line 123, column 21
[WARNING] 
[WARNING] Some problems were encountered while building the effective model for com.spotify:apollo-environment:jar:2.0.0-SNAPSHOT
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-surefire-plugin is missing. @ com.spotify:apollo-parent:2.0.0-SNAPSHOT, /Users/eduardo/Development/apollo/pom.xml, line 123, column 21
[WARNING] 
[WARNING] Some problems were encountered while building the effective model for com.spotify:apollo-meta:jar:2.0.0-SNAPSHOT
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-surefire-plugin is missing. @ com.spotify:apollo-parent:2.0.0-SNAPSHOT, /Users/eduardo/Development/apollo/pom.xml, line 123, column 21
[WARNING] 
[WARNING] Some problems were encountered while building the effective model for com.spotify:apollo-route:jar:2.0.0-SNAPSHOT
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-surefire-plugin is missing. @ com.spotify:apollo-parent:2.0.0-SNAPSHOT, /Users/eduardo/Development/apollo/pom.xml, line 123, column 21
[WARNING] 
[WARNING] Some problems were encountered while building the effective model for com.spotify:apollo-test:jar:2.0.0-SNAPSHOT
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-surefire-plugin is missing. @ com.spotify:apollo-parent:2.0.0-SNAPSHOT, /Users/eduardo/Development/apollo/pom.xml, line 123, column 21
[WARNING] 
[WARNING] Some problems were encountered while building the effective model for com.spotify:apollo-extra:jar:2.0.0-SNAPSHOT
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-surefire-plugin is missing. @ com.spotify:apollo-extra:[unknown-version], /Users/eduardo/Development/apollo/apollo-extra/pom.xml, line 92, column 21
[WARNING] 
[WARNING] Some problems were encountered while building the effective model for com.spotify:apollo-entity:jar:2.0.0-SNAPSHOT
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-surefire-plugin is missing. @ com.spotify:apollo-parent:2.0.0-SNAPSHOT, /Users/eduardo/Development/apollo/pom.xml, line 123, column 21
[WARNING] 
[WARNING] Some problems were encountered while building the effective model for com.spotify:apollo-http-service:jar:2.0.0-SNAPSHOT
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-surefire-plugin is missing. @ com.spotify:apollo-parent:2.0.0-SNAPSHOT, /Users/eduardo/Development/apollo/pom.xml, line 123, column 21
[WARNING] 
[WARNING] Some problems were encountered while building the effective model for com.spotify:apollo-slack:jar:2.0.0-SNAPSHOT
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-surefire-plugin is missing. @ com.spotify:apollo-parent:2.0.0-SNAPSHOT, /Users/eduardo/Development/apollo/pom.xml, line 123, column 21
[WARNING] 
[WARNING] Some problems were encountered while building the effective model for com.spotify:apollo-jetty-http-server:jar:2.0.0-SNAPSHOT
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-surefire-plugin is missing. @ com.spotify:apollo-jetty-http-server:[unknown-version], /Users/eduardo/Development/apollo/modules/jetty-http-server/pom.xml, line 103, column 21
[WARNING] 
[WARNING] Some problems were encountered while building the effective model for com.spotify:apollo-okhttp-client:jar:2.0.0-SNAPSHOT
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-surefire-plugin is missing. @ com.spotify:apollo-parent:2.0.0-SNAPSHOT, /Users/eduardo/Development/apollo/pom.xml, line 123, column 21
[WARNING] 
[WARNING] Some problems were encountered while building the effective model for com.spotify:apollo-metrics:jar:2.0.0-SNAPSHOT
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-surefire-plugin is missing. @ com.spotify:apollo-parent:2.0.0-SNAPSHOT, /Users/eduardo/Development/apollo/pom.xml, line 123, column 21
[WARNING] 
[WARNING] Some problems were encountered while building the effective model for com.spotify:apollo-parent:pom:2.0.0-SNAPSHOT
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-surefire-plugin is missing. @ line 123, column 21
[WARNING] 
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING] 
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
[WARNING] 
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Build Order:
[INFO] 
[INFO] Spotify Apollo Parent
[INFO] Spotify Apollo Bill of Materials
[INFO] Spotify Apollo Service Core (aka Leto)
[INFO] Spotify Apollo API Interfaces
[INFO] Spotify Apollo Route
[INFO] Spotify Apollo API Implementations
[INFO] Spotify Apollo Metadata
[INFO] Spotify Apollo API Environment
[INFO] Spotify Apollo Extra
[INFO] Spotify Apollo okhttp Client Module
[INFO] Spotify Apollo Metrics Module
[INFO] Spotify Apollo Testing Helpers
[INFO] Spotify Apollo Entity Middleware
[INFO] Spotify Apollo Jetty HTTP Server Module
[INFO] Spotify Apollo HTTP Service
[INFO] Spotify Apollo Slack Module
[INFO] 
[INFO] ------------------------------------------------------------------------
[INFO] Building Spotify Apollo Parent 2.0.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO] 
[INFO] --- maven-enforcer-plugin:1.4.1:enforce (enforce) @ apollo-parent ---
[INFO] 
[INFO] --- license-maven-plugin:1.8:check-file-header (check-file-header) @ apollo-parent ---
[WARNING] No file to scan.
[INFO] 
[INFO] 
[INFO] ------------------------------------------------------------------------
[INFO] Building Spotify Apollo Bill of Materials 2.0.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO] 
[INFO] --- maven-enforcer-plugin:1.4.1:enforce (enforce) @ apollo-bom ---
[INFO] 
[INFO] --- license-maven-plugin:1.8:check-file-header (check-file-header) @ apollo-bom ---
[WARNING] No file to scan.
[INFO] 
[INFO] 
[INFO] ------------------------------------------------------------------------
[INFO] Building Spotify Apollo Service Core (aka Leto) 2.0.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO] 
[INFO] --- maven-enforcer-plugin:1.4.1:enforce (enforce) @ apollo-core ---
[INFO] 
[INFO] --- license-maven-plugin:1.8:check-file-header (check-file-header) @ apollo-core ---
[INFO] Will search files to update from root /Users/eduardo/Development/apollo/apollo-core/src/main/java
[INFO] Will search files to update from root /Users/eduardo/Development/apollo/apollo-core/src/test/java
[INFO] Scan 13 files header done in 36,35ms.
[INFO] All files are up-to-date.
[INFO] 
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ apollo-core ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 1 resource
[INFO] 
[INFO] --- maven-compiler-plugin:3.5.1:compile (default-compile) @ apollo-core ---
[INFO] Nothing to compile - all classes are up to date
[INFO] 
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ apollo-core ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 1 resource
[INFO] 
[INFO] --- maven-compiler-plugin:3.5.1:testCompile (default-testCompile) @ apollo-core ---
[INFO] Nothing to compile - all classes are up to date
[INFO] 
[INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ apollo-core ---
[INFO] Surefire report directory: /Users/eduardo/Development/apollo/apollo-core/target/surefire-reports

-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running com.spotify.apollo.core.ServicesTest
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.mockito.cglib.core.ReflectUtils$2 (file:/Users/eduardo/.m2/repository/org/mockito/mockito-core/1.10.19/mockito-core-1.10.19.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
WARNING: Please consider reporting this to the maintainers of org.mockito.cglib.core.ReflectUtils$2
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.256 sec
Running com.spotify.apollo.core.ServiceImplTest
Jan 25, 2018 4:13:29 PM com.google.inject.internal.MessageProcessor visit
INFO: An exception was caught and reported. Message: java.lang.RuntimeException: Fail foobar
java.lang.RuntimeException: Fail foobar
        at com.spotify.apollo.core.ServiceImplTest$1.configure(ServiceImplTest.java:506)
        at com.google.inject.AbstractModule.configure(AbstractModule.java:62)
        at com.google.inject.spi.Elements$RecordingBinder.install(Elements.java:340)
        at com.google.inject.spi.Elements.getElements(Elements.java:110)
        at com.google.inject.internal.InjectorShell$Builder.build(InjectorShell.java:138)
        at com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:104)
        at com.google.inject.Guice.createInjector(Guice.java:96)
        at com.spotify.apollo.core.ServiceImpl.initInstance(ServiceImpl.java:196)
        at com.spotify.apollo.core.ServiceImpl.start(ServiceImpl.java:148)
        at com.spotify.apollo.core.ServiceImpl.start(ServiceImpl.java:112)
        at com.spotify.apollo.core.ServiceImpl.start(ServiceImpl.java:107)
        at com.spotify.apollo.core.ServiceImplTest.testExceptionDuringInit(ServiceImplTest.java:517)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:564)
        at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
        at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
        at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
        at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
        at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:298)
        at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:292)
        at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
        at java.base/java.lang.Thread.run(Thread.java:844)

Tests run: 42, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.554 sec

Results :

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

[INFO] 
[INFO] --- maven-jar-plugin:3.0.2:jar (default-jar) @ apollo-core ---
[INFO] Building jar: /Users/eduardo/Development/apollo/apollo-core/target/apollo-core-2.0.0-SNAPSHOT.jar
[INFO] 
[INFO] ------------------------------------------------------------------------
[INFO] Building Spotify Apollo API Interfaces 2.0.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO] 
[INFO] --- maven-enforcer-plugin:1.4.1:enforce (enforce) @ apollo-api ---
[INFO] 
[INFO] --- license-maven-plugin:1.8:check-file-header (check-file-header) @ apollo-api ---
[INFO] Will search files to update from root /Users/eduardo/Development/apollo/apollo-api/src/main/java
[INFO] Will search files to update from root /Users/eduardo/Development/apollo/apollo-api/src/test/java
[INFO]  - ignore file (detected %%Ignore-License) /Users/eduardo/Development/apollo/apollo-api/src/main/java/com/spotify/apollo/QueryStringDecoder.java
[INFO] Scan 36 files header done in 40,676ms.
[INFO] 
 * uptodate header on 35 files.
 * ignore header on 1 file.
[INFO] 
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ apollo-api ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory /Users/eduardo/Development/apollo/apollo-api/src/main/resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.5.1:compile (default-compile) @ apollo-api ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 24 source files to /Users/eduardo/Development/apollo/apollo-api/target/classes
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO] 
[INFO] Spotify Apollo Parent .............................. SUCCESS [  0.968 s]
[INFO] Spotify Apollo Bill of Materials ................... SUCCESS [  0.009 s]
[INFO] Spotify Apollo Service Core (aka Leto) ............. SUCCESS [  1.971 s]
[INFO] Spotify Apollo API Interfaces ...................... FAILURE [  0.955 s]
[INFO] Spotify Apollo Route ............................... SKIPPED
[INFO] Spotify Apollo API Implementations ................. SKIPPED
[INFO] Spotify Apollo Metadata ............................ SKIPPED
[INFO] Spotify Apollo API Environment ..................... SKIPPED
[INFO] Spotify Apollo Extra ............................... SKIPPED
[INFO] Spotify Apollo okhttp Client Module ................ SKIPPED
[INFO] Spotify Apollo Metrics Module ...................... SKIPPED
[INFO] Spotify Apollo Testing Helpers ..................... SKIPPED
[INFO] Spotify Apollo Entity Middleware ................... SKIPPED
[INFO] Spotify Apollo Jetty HTTP Server Module ............ SKIPPED
[INFO] Spotify Apollo HTTP Service ........................ SKIPPED
[INFO] Spotify Apollo Slack Module ........................ SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 4.218 s
[INFO] Finished at: 2018-01-25T16:13:30+01:00
[INFO] Final Memory: 28M/93M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.5.1:compile (default-compile) on project apollo-api: Fatal error compiling: java.lang.NoClassDefFoundError: javax/annotation/Generated: javax.annotation.Generated -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
[ERROR] 
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn <goals> -rf :apollo-api

Requests with "Transfer-Encoding: chunked" wrongly conclude that no payload is being sent

When sending a request with the header Transfer-Encoding: chunked, Apollo is concluding that no payload is being sent due to the fact that getting the content length of such request may return -1 (unknown length). Such header indicates that the payload is being sent as a series of chunks.

I think that Apollo should still try to read the streamed payload in such a case before concluding that it is empty. I am wrapping up a fix for this which I expect to submit later today.

Allocate new groupId and package for Apollo 2.x

This is suggestion for the next Major version of Apollo.

Because Apollo is a multi-module project that also exposes an API, there are many opportunities for accidental binary compatibility with 1.x at runtime. This threatens the stability of projects using Apollo, especially in complex environments.

My suggestion is to introduce a new groupId (com.spotify.apollo2) and move everything into new packages (com.spotify.apollo2). This way, maven dependencies are explicit, and major version compatibility would have to be explicitly addressed instead of by accident.

add methods to Request to add parameters

When writing unit/integration tests that use ServiceHelper to test routes, it would be helpful if I could add parameters to a Request object with a method like request.withParameter("foo", "bar") similar to existing "with" methods like withHeader, withPayload etc.

Currently in order to set the request parameters that are sent in a Request I have to add them in the URI like Request.forUri("http://service/foo?bar=bat"), but I would prefer to do this programmatically.

Dynamically created metric descriptors

The addition of metrics (#122, #123, #124, #125) introduces dynamically created metrics descriptors - so a new metrics descriptor will be created for previously unknown status codes when they are first encountered. This issue moves a discussion from a comment on #122 to a more visible place.

Incorrect documentation of RequestContext#pathArgs

apollo/apollo-api/src/main/java/com/spotify/apollo/RequestContext.java

Line 49 in 814aaf7

* "/somewhere/over/the%32rainbow", then the map will be

Route.sync("GET", "/test/<thing>",
           rc -> Response.forPayload(ByteString.encodeUtf8(rc.pathArgs().get("thing")))),

  @Test
  public void test() throws Exception {
    final Response<ByteString> response = service.request(Request.forUri(
        "http://localhost:8080/test/the%32rainbow"))
        .toCompletableFuture().get();

    final String expectedPayload = "the%32rainbow";

    assertEquals(expectedPayload, response.payload().get().utf8());
  }

Expected: the%32rainbow
Actual: the2rainbow

Route execution elapsed time

Hi,
I'm using Apollo 1.6.5. Is there a way to know the routes elapsed time?

I'd like to know if there is something that can tell me, for each called route, the execution time.
Is possible for example using some Middleware?
Thanks
Gianluca

More graceful shutdown

Currently, when shutting down, there's a fairly high chance that requests in process will fail. This has been somewhat intentional, since clients in a distributed system should be resilient to transient failures anyway. It turns out that a large number of service clients in our internal ecosystem at least are not sufficiently resilient, and that improving the shutdown process to increase the chance of requests getting successfully processed before the service stops will improve the user experience.

Known issues to address:

• Clients can be closed while they still have outstanding requests, leading to failures when replies come in.
• Servers (like HttpServerImpl) don't wait for all outstanding requests to finish processing before stopping.

Interface classes in apollo-api-impl

There are some interface/abstract classes in apollo-api-impl that are very useful for hooking into Apollo, for instance:

• EndpointRunnableFactory
• ForwardingOngoingRequest
• OngoingRequest
• RequestRunnableFactory

There are probably more. This means that other modules, like apollo-meta, etc., have a dependency on an internal implementation module. It seems like these should be separated out into their own artifact. Probably, it would be good to keep apollo-api as the API definitions for application developers, and add a new set of API definitions for assembly/platform developers?

how to run this with gradle ?

it hangs after gradlew run, but no error.

import com.spotify.apollo.Environment;
import com.spotify.apollo.RequestContext;
import com.spotify.apollo.Response;
import com.spotify.apollo.httpservice.HttpService;
import com.spotify.apollo.httpservice.LoadingException;
import com.spotify.apollo.route.Route;

public final class App {

    public static void main(String... args) throws LoadingException {
        HttpService.boot(App::init, "my-app", args);
    }

    static void init(Environment environment) {
        environment.routingEngine()
            .registerAutoRoute(Route.sync("GET", "/", rc -> "hello world"));
    }
 }

Download resource

Is there a way to implement dowload service using Apollo?

Swagger or ReST Documentation

Hi guys,
is there a way to integrate apollo and swagger?

Thanks
Gianluca

Clarify requirements on and behaviour of MetaModule

Some things that are currently more or less broken:

• #13
• MetaModule specifies a 'container version' which is hard-coded to 'apollo-standalone' + the apollo version. The latter is retrieved from a file named 'metaDescriptor.properties' on the class path.
• The 'meta' API is exposed on the same port as the main service, under a 'path tree' starting with '_meta'.
• The APIs are defined in apollo-api-impl, which is not 'public', making it unclear if we're breaking backwards compatibility by changing something like MetaGatherer.

Is there support for CORS? If not, are there plans to add it? If not, can I submit a PR?

Is there support for CORS? If not, are there plans to add it? If not, can I submit a PR?

Ideally there would be out-of-the-box CORS support. Adding something like this to the .conf file perhaps.

http.cors.enabled : true
http.cors.allow-origin : "*"
http.cors.allow-methods : OPTIONS, HEAD, GET, POST, PUT, DELETE
http.cors.allow-headers : X-Requested-With,X-Auth-Token,Content-Type, Content-Length

Spotify people who work with our internal version of apollo will know more about what I'm getting at.

StubClient respondTo order

Copied from internal repo, by jwiklund:

The stub client uses the first stubbed response, it would be convenient if it took the last match to allow specific tests to override generic stubs.

eg:

@before
stubClient.respond(OK).toEverything()

@test
stubClient.respond(FAIL).toSomethingSpecific()

Change master branch back to 1.x branch?

The master branch currently has the unreleased 2.0 version of Apollo which doesn't seem to have any active plans for release or further development.

When people make pull requests to change behavior in 1.x, they tend to instinctively do this against master, not realizing the state that it is in. They then need to go back and apply their change to the 1.x branch as well (see #221 #220 #217 etc).

Since the 2.0 version doesn't have plans for a release or finishing any time soon, would it be possible to flip the branches around so that there is a 2.0 branch for the 2.0 refactoring and master reflects the 1.x versions being released?

Add map of headers to Request

I think it would be convenient if Request accepted a Map<String, String> headers so code can go from

Request request = Request.forUri(uri, "GET");
request = request.withPayload(ByteString.encodeUtf8(json));
for (Map.Entry<String, String> h : context.getHeaders().entrySet()) {
  request = request.withHeader(h.getKey(), h.getValue());
}

to

Request request = Request.forUri(uri, "GET");
request = request.withPayload(ByteString.encodeUtf8(json));
request = request.withHeaders(context.getHeaders());

An alternative, would be to allow a RequestBuilder that lets me avoid the reassignment as well.

Clarify the close connection between ServiceHelper and assembly

ServiceHelper helps do integration testing of an assembly, but that testing can easily break (via Environment.resolve, mostly) due to missing modules. Therefore, there should be different ServiceHelper instantiations for each assembly, where each instantiation can ensure that the right module set for that assembly is in use.

See #163 for an example of this breaking.