Dispatch v0.13.0

The maintainers of and contributors to Dispatch are pleased to announce the release of Dispatch v0.13.0. This release is a stable release for the v0.13.x series. The change log for this release can be viewed on GitHub.

The following changes have been made since the v0.12.x series:

• Breaking: Async HTTP Client version is upgraded to 2.0.32. @fbascheper did a heroic amount of work to make this change. This is technically a breaking change since AHC 2.x reorganized all their packages so you'll probably have to adjust imports in your application when you move up to this version.
• Breaking: The implicit dispatch. implyReq, which was depreciated in 0.11.0, has been removed. Please use RequestBuilder.underlying where needed instead.
• Deprecation: Http.default replaces direct use of the Http singleton as an executor. See the v0.13.0-M2 release notes for more details.
• Deprecation: The use of configure is now deprecated. It was easy to accidentally use it to cause resource leaks without realizing it. Please use Http.withConfiguration or closeAndConfigure on an executor instance to avoid resource leaks. See the v0.13.0-M2 release notes for more details.

Dispatch v0.13.0-M2

The maintainers of and contributors to Dispatch are pleased to announce the release of Dispatch v0.13.0-M2. This release is a milestone pre-release for the v0.13.x series. The change log for this release can be viewed on GitHub.

This release will become the final v0.13.0 release on June 15th, 2017, unless any major bugs are reported and need to be fixed.

Below are some highlights from this release since v0.13.0-M1:

Http singleton is no longer an executor, using Http.apply is now deprecated

Since Dispatch started, you've been able to use the HTTP singleton to make requests to HTTP services directly. For example:

Http(myReq > as.String)

This usage is now deprecated. The long in short here is that treating the Http singleton created a good bit of awkwardness when it came to figuring out how to deal with cases where people needed a custom configuration for their HTTP executor. We got many, many bugs over the years where people would invoke configure on the Http singleton and end up with a resource leak. It also wasn't clear that even referencing the Http singleton somewhere would allocate resources.

Furthermore, it was easy for people to make the mistake of writing something to the effect of:

for (task <- myBatchTasks) {
  val exec = Http()
  exec(...)
}

and ending up with a huge resource leak in their application.

To combat this a few specific changes have been made:

• If you want to create a new instance of the Http case class directly, you'll have to manually provide a client builder instance. You can use Http.defaultClientBuilder directly or as a starting point, but this should hopefully make it harder to fat-finger a resource leak in your application.
• Http.default is the new way to use a default, globally available executor. It's a lazy val and won't allocate resources until it is accessed.
• The apply methods on the Http singleton still work to ease in migration, but will use Http.default under the hood and throw a deprecation warning on compile.
• The Http singleton is no longer an instance of an executor, so invoking things like Http.configure will no longer work. We instead provide Http.withConfiguration which will vend a new executor with your desired configuration without allocating resources on the default executor.

The configure method on executors is now deprecated

Part of the motivation for the Http singleton changes from above was the fact that in the old world you could invoke the .configure method on the Http singleton. There were a number of pull requests that suggested solutions for this and several of them were implemented. Including, in 0.13.x, having the Http case class take a ClientBuilder instead of a DefaultAsyncHttpClient.

However, we were still faced with needing to make a breaking API change.

The configure method in its old form could still create resource leaks that couldn't be resolved if used in its old form. To fix this problem a new method, closeAndConfigure has been added to the Http case class. This method will first close the underlying client in the executor, and then return a new instance of Http with the requested configuration.

In the future, if you need to create a new Http instance while leaving your old Http instance functional, we recommend manually invoking the copy behavior on the case class. Something like:

import org.asynchttpclient._

val myHttp1 = Http.default
val newBuilder = new Builder(myHttp1.clientBuilder.build)
val myHttp2 = Http(newBuilder)

In the example above, myHttp1 and myHttp2 are both still usable and it's explicit to the developer that they have allocated additional resources.

This method is consistent with the methods added in the 0.12.x series and allows you to continue using .configure if that's what you really want to do. My hope is that this will make migrating to the new, "correct"

Dispatch v0.12.2

The maintainers of and contributors to Dispatch are pleased to announce the release of Dispatch v0.12.2. This release is a stable release for the v0.12.x series. The change log for this release can be viewed on GitHub. Below are some highlights from this release:

AHC Version Bump

The 0.12.x series is now using AHC 1.9.40.

Using Http.apply is now deprecated

Since Dispatch started, you've been able to use the HTTP singleton to make requests to HTTP services directly. For example:

Http(myReq > as.String)

This usage is now deprecated. The long in short here is that treating the Http singleton created a good bit of awkwardness when it came to figuring out how to deal with cases where people needed a custom configuration for their HTTP executor. We got many, many bugs over the years where people would invoke configure on the Http singleton and end up with a resource leak. It also wasn't clear that even referencing the Http singleton somewhere would allocate resources.

Furthermore, it was easy for people to make the mistake of writing something to the effect of:

for (task <- myBatchTasks) {
  val exec = Http()
  exec(...)
}

and ending up with a huge resource leak in their application.

To combat this a few specific changes have been made:

• Http.default is the new, preferred way to use a default, globally available executor. Starting in 0.13.x it will ensure that it doesn't allocate resources until it's referenced.
• The apply methods on the Http singleton still work to ease in migration, but we recommend switching to using Http.default if you can.

The configure method on executors is now deprecated

Part of the motivation for the Http singleton changes from above was the fact that in the old world you could invoke the .configure method on the Http singleton. There were a number of pull requests that suggested solutions for this and several of them were implemented.

However, we were still faced with needing to make a breaking API change for 0.12.x. That is something I wanted to avoid.

As a compromise I've implemented a new method, closeAndConfigure has been added to the Http case class. This method will first close the underlying client in the executor, and then return a new instance of Http with the requested configuration.

In the future, if you need to create a new Http instance while leaving your old Http instance functional, we recommend manually invoking the copy behavior on the case class, but for now continue using .configure in 0.12.x if you need that behavior.

Dispatch v0.13.0-M1

The maintainers of and contributors to Dispatch are pleased to announce the release of Dispatch v0.13.0-M1. This release is an initial milestone pre-release for the v0.13.x series. The change log for this release can be viewed on GitHub. Below are some highlights from this release:

• Async HTTP Client version is upgraded to 2.0.32
• The implicit dispatch. implyReq, which was depreciated in 0.11.0, has been removed. Please use RequestBuilder.underlying where needed instead.

Thanks to @fbascheper for doing the work to get this release done.

This release is immediately available on Maven Central.

Please shoot us a note on the mailing list or in GitHub Issues if you experience issues with this release. I'll be monitoring issue activity closely over the next few weeks when determining whether or not to issue subsequent milestone releases or declaring 0.13.x final.

Dispatch v0.12.1

The maintainers of and contributors to Dispatch are pleased to announce the release of Dispatch v0.12.1. The change log for this release can be viewed on GitHub. Below are some highlights from this release:

• Bug #122 has been fixed by PR #123. This means that proxy settings should behave as expected.
• A bugfix was contributed to prevent the duplication of query params on string bodies
• Our json4s dependency was version bumped to 3.5.1
• Various upgrades to our build process

Thanks to @henry0312, @fbascheper, @mzsnelling, @xuwei-k, @SethTisue, and @mdedetrich for their contributions to this release.

This release is immediately available from Maven Central.