Skip to content

Dispatch v0.12.2

Compare
Choose a tag to compare
@farmdawgnation farmdawgnation released this 04 Jun 16:36
· 241 commits to main since this release
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.