Wiremock: Unable to create custom StringValuePattern

[karolzmuda]

Hi,

I wanted to create my own custom StringValuePattern in my project but unfortunately I'm not able to do so due to this Map present in StringValuePatternJsonDeserializer which maps StringValuePatterns to json names (I'm getting JsonMappingException: null is not a valid comparison):

private static final Map<String, Class<? extends StringValuePattern>> PATTERNS =
        new ImmutableMap.Builder<String, Class<? extends StringValuePattern>>()
            .put("equalTo", EqualToPattern.class)
            .put("equalToJson", EqualToJsonPattern.class)
            .put("matchesJsonPath", MatchesJsonPathPattern.class)
            .put("equalToXml", EqualToXmlPattern.class)
            .put("matchesXPath", MatchesXPathPattern.class)
            .put("contains", ContainsPattern.class)
            .put("matches", RegexPattern.class)
            .put("doesNotMatch", NegativeRegexPattern.class)
            .put("anything", AnythingPattern.class)
            .build();

Am I missing something or is it really currently not possible to create custom StringValuePattern?

Why this json name is stored in private Map and not set as annotation on each StringValuePattern class?

[tomakehurst]

It's not really meant to be extensible at the moment. I suggest taking a look at custom matchers: http://wiremock.org/docs/extending-wiremock/#custom-request-matchers

[karolzmuda]

1. Is there any particular reason why StringValuePattern cannot be extensible or is it just the design decision? I think that some people may benefit from this option and it won't hurt anybody in the process ;)

2. Is it possible to combine Custom Request Matcher with standard MappingBuilder? In fact using MappingBuilder covers 95% of my matching rules and additionaly I would like only to test one particular request header with my custom rules including some custom logic. If I would have to include all this standard matching rules in Custom Request Matcher it would be really a lot of unnecessary work.

[tomakehurst]

1. I can see why it'd be useful to open it up to extension, but at the time I was originally working on it a) I didn't want to make it part of the published API in case I wanted to adjust the design after releasing it, b) Making JSON serialisation work properly would be hard, and I've never felt I've had time to solve this problem properly.

2. This has come up a couple of times, and it's logged as feature request #719

[karolzmuda]

Ok, thank you for explanation.

Anyway, you are doing really great work :)

[tomakehurst]

Thanks!