I made use of the new Events of version `3.0.0-bet...
# wiremock-java
I made use of the new Events of version
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
was set to
. • 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
. 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
(UUID) field, is this sufficient for what you’re trying? • You can use
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
ExtensionFactory works like a charm. Adaption is pushed
🎉 1
Yes, the ServeEvent is created at the start of request processing and is carried through to the end
So the ID is consistent
👍 1
@Tom is it possible to extend the
to also get the
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.
👍 1
If you just need the ID you might be able to cheat a bit for now by making a request filter that adds it as a request header
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