This needed when writing integration tests to gain access to data access layers and such without code duplication.

For example.

final ServiceHelper helper = ServiceHelper.create(new Application(), "application")
        .withModule(new ApplicationModule())
        .withModule(new FakeDatabaseLayer());

helper.start();

final Database database = helper.resolve(Database.class);

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.

This fixes an issue where the error-reply-ratio metric will show un-predictable behavior after sites or hosts have been drained without the hosts being restart afterwards.

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.

also upgrade okio

okhttp 2.x is obsolete, and according to https://github.com/square/okhttp/blob/master/CHANGELOG.md#version-300-rc1 there should be no risk to upgrade.

This is a set of related changes to improve the metadata collection and presentation. Highlights:

• Move the meta-related interfaces and classes into their own module (except one, IncomingCallsGatherer, which is still in apollo-api-impl).
• Fix #13 - don't track content type at all.
• Fix #63 - make the assembly name used configurable.
• Make it possible for assemblies to define a sort order for client decorators rather than leaving it random. This is necessary to guarantee that outgoing calls will be gathered (if the OutgoingCallsDecorator would end up after the the HttpClientDecorator, it would never be executed).

instead of adding the header without check, reset it in favor of that from incoming request.

Does this make sense? Do we have use case replying on multiple Authorization header?

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.

A set of middleware for working with typed route handlers.

The gist of it

class MyApplication {

  private static final ObjectMapper OBJECT_MAPPER = new ObjectMapper();

  static void init(Environment environment) {
    MyApplication app = new MyApplication();
    EntityMiddleware entity = EntityMiddleware.forCodec(JacksonEntityCodec.forMapper(OBJECT_MAPPER));

    Route<SyncHandler<Response<ByteString>>> route = Route.with(
        entity.direct(Person.class),
        "PUT", "/person/<id>",
        rc -> person -> app.updatePerson(rc.pathArgs().get("id"), person));

    // ...
  }

  Person updatePerson(String id, Person person) {
    // ...
  }
}

There's also support for other handler signatures. See README in PR.

The root pom does not define a version for maven-surefire-plugin, which this pom seems to assume.

[WARNING] Some problems were encountered while building the effective model for com.spotify:apollo-bom:pom:1.8.1-SNAPSHOT [WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-surefire-plugin is missing. @ com.spotify:apollo-parent:1.8.1-SNAPSHOT, /root/apollo/pom.xml, line 137, column 21

also upgrade okio

okhttp 2.x is obsolete, and according to https://github.com/square/okhttp/blob/master/CHANGELOG.md#version-300-rc1 there should be no risk to upgrade.

backport of #220