Greg Methvin

Hi @disbrain, Looking up the exception you got, it appears the same solution has been [mentioned on stackoverflow](http://stackoverflow.com/a/21898970) quite long ago, though there are no references to CompletableFuture. You can...

You've discovered an interesting issue here... > I have no idea why in #7621 those UserId classes were made to extends AnyVal. This is a pretty standard use case for...

@kijuky did you want to add the other changes in this PR? They're related so I think it's fine. But if you prefer you can open a different PR.

Are there any potential compatibility issues with this upgrade? I'm not that familiar with the JPA specifications so I'm not sure how much of a breaking change this would be...

ok, this sounds fine then.

There are some compatibility breakages in 10.1.x: https://doc.akka.io/docs/akka-http/current/migration-guide/migration-guide-10.1.x.html. It should be safe to upgrade in your own code if you follow the migration guide, but it would be a bad...

Another possibility is to use a static AtomicInteger that you increment each time. With a large enough port range that would provide a more deterministic way to avoid conflicts.

@delitescere Neither scheme really takes into account non-Play apps. My thought was that with a sequential scheme that wraps around, you could almost guarantee that tests running in the same...

@delitescere Since there is no universal solution to this, why not just extend the trait and override the testServerPort yourself? That way you can use any scheme you want.

@jroper I wish I had thought of that earlier. Obviously the best solution. We can close this once we update all the test APIs.