I made use of the new Events of version

3.0.0-beta-11

in the state extension. A PR is available at: https://github.com/wiremock/wiremock-extension-state/pull/4 for you to give feedback and see it in use. Some things I stumbled upon: • I could only get response templating to work when both

templatingEnabled

and

globalTemplating

was set to

true

. • For one functionality I had in mind it would be great if a request gets a unique ID . What do you think? • I'm currently at 4 classes I have to add for the whole set. It hardly makes sense to register them in isolation, so I wonder whether we can add a "collection" extension which can register multiple events + extensions in one shot (similar to what is already done with

TemplateHelperProviderExtension

. I can provide an proposal + PR if this something you see as beneficial

Hi @Dirk Bolte, thanks for sharing this. To address your points in turn: • Response templating defaults to being local, meaning you have to activate it per stub. Did you add the

"transformers": ["response-template"]

element to your stub when you declared it? • ServeEvents already have an

id

(UUID) field, is this sufficient for what you’re trying? • You can use

ExtensionFactory

for exactly this purpose, and be able to inject core WireMock services while you’re doing it. Alternatively you can have one class that implements all the extension interfaces you need to support.

Is the event Id the same for the whole request? Then it would work. Will make use the extension factory, thx

Yes, the ServeEvent is created at the start of request processing and is carried through to the end

@Tom is it possible to extend the

RequestMatcherExtension

to also get the

ServeEvent

so that I can access the ID?

Was going to start looking at this in more detail in my next batch of changes. In principle yes, but I’ll let you know when I’ve actually attempted it.

as background: I want to add counter matchers to state to be able to simulate different behavior on first or second call. I'm about to add one for state updates already but for request matchers, I need an identifier prevent multiple records for the same request