Package org.mockserver.matchers

Class ConditionalRequestMatcher

java.lang.Object
org.mockserver.model.ObjectWithReflectiveEqualsHashCodeToString
org.mockserver.matchers.NotMatcher<RequestDefinition>
org.mockserver.matchers.AbstractHttpRequestMatcher
org.mockserver.matchers.ConditionalRequestMatcher
All Implemented Interfaces:
HttpRequestMatcher, Matcher<RequestDefinition>
public class ConditionalRequestMatcher extends AbstractHttpRequestMatcher
Matcher for ConditionalRequestDefinition (if-then-else request matching).

Composes the existing HttpRequestMatcher machinery for each branch rather than reimplementing matching: the if, then and else branches are each compiled to their own HttpRequestMatcher via MatcherBuilder. Evaluation is: 

   if (ifMatcher.matches(request)) {
       result = thenMatcher.matches(request)
   } else {
       result = elseMatcher != null ? elseMatcher.matches(request) : true
   }

The branch matchers are built in the same plane (control vs data) as this matcher so that the conditional behaves consistently whether it is created from an Expectation (data plane) or a RequestDefinition filter (control plane).

Concurrency: like HttpRequestPropertiesMatcher, a single instance is shared between the control plane (which rebuilds the compiled branch matchers in apply(org.mockserver.model.RequestDefinition) — a single-writer path) and the data plane (which reads them in matches(org.mockserver.matchers.MatchDifference, org.mockserver.model.RequestDefinition) from many Netty event-loop threads). All per-criterion compiled state lives in an immutable ConditionalRequestMatcher.Compiled holder built fully inside apply() and published through a single volatile reference (compiled); matches() snapshots that reference once on entry, so it sees either the whole old set of branch matchers or the whole new one — never a torn mix.

Author:
jamesdbloom