Leonard Brünings

@AndreasTu, as I mentioned [earlier](https://github.com/spockframework/spock/pull/1575#issuecomment-1463618870), I'll write some documentation and polish it later. Thanks for your comments in any case. However, I'm looking for a review of the correctness of...

> Btw. could we also support where (and upcoming filter) blocks in a sensible way? I don't think it would be intuitive or really helpful. They run outside the normal...

Forgot to publish my responses 😅

> Btw, I wonder, if it is still a [recommended way](https://github.com/szpak/spock-jpa-flush-enforcer/blob/1f0ff33383ea62c557585cfe9fdab807016c6e86/spock-jpa-flush-enforcer/src/main/java/pl/solidsoft/spock/flush/EnforceJpaSessionFlushExtension.java#L60) to decide if the block listener was intended for the current iteration? @szpak, can you motivate this use case...

> > @szpak, can you motivate this use case more? At first glance, I'd try to register a block listener that can handle all iterations instead of one per iteration....

> > > Hmm, I think the main problem was to get the `invocation` instance to obtain the current field instance. As a result, I put `IBlockListener` inside `AbstractMethodInterceptor` which...

@szpak FWIW, you can probably get away with using a single instance of each and a ThreadLocal to share the data from the interceptor to the listener.

@renatoathaydes do you have any comments about the new listeners?

@Vampire, @szpak, @AndreasTu: Historically, Spock ignored block labels that were GString expressions, e.g., `when: "user ${user.name}"` instead, those were kept as standalone GStrings doing mostly nothing, except for `expect`/`then` blocks...

@szpak you should just register the blocklister once for the feature where you add the interationInterceptor instead of adding/removing it every time. Otherwise, you'll run into problems in parallel execution...