Different expectations with different path params do not work when using verify

[mcassidygamma]

When a request is received, if there are mutliple expectations with different path parameters, the recorded request will include all path path paramters from all the expectations (up until the point it is matched). This means that such request cannot be verified succesfully.

It seems that when iterating over expectations, when resolving path parameters, the received request has its path paramters set reqgardless of whether or not it matched the expectation.

Here is an example:

public class MockTest
{
	public static void main(final String... strings)
	{
		try (final ClientAndServer clientAndServer = new ClientAndServer(1080))
		{
			clientAndServer.when(HttpRequest.request().withMethod("GET").withPath("/three/{three}/four/{four}").withPathParameter("three", "yellow")
					.withPathParameter("four", "red"))
					.respond(HttpResponse.response());
			clientAndServer
					.when(HttpRequest.request().withMethod("GET").withPath("/one/{one}/two/{two}").withPathParameter("one", "blue")
							.withPathParameter("two", "green"))
					.respond(HttpResponse.response());

			final WebTarget target = ClientBuilder.newBuilder().build().target("http://localhost:1080");

			target.path("/one/blue/two/green").request().get();

			// This works, but it should not work
			clientAndServer.verify(HttpRequest.request().withPath("/one/{one}/two/{two}").withPathParameter("one", "blue")
					.withPathParameter("two", "green").withPathParameter("three", "blue").withPathParameter("four", "green"));

			// This should work but it does not work
			clientAndServer.verify(HttpRequest.request().withPath("/one/{one}/two/{two}").withPathParameter("one", "blue")
					.withPathParameter("two", "green"));

			clientAndServer.stop();
		}
	}
}

The request that is sent, is recorded by mock server as having path parameters: one, two, three and four - because the path parameters from both expectations are include. If the expectations were added the other way around, this would work, but then requests sent to /three/yellow/four/red would have the problem instead.