>wrapper registry I think wrapper is just a single case, and it is unlikely "wrapper registry" would be reused in the future. Test plan transformations will likely be on a case-by-case basis.
>that might come to a curious mind. Let me put it this way: expression transformation is a very common pattern in optimizing compilers. See https://stackoverflow.com/a/21295297/1261287 In other words, we have two options: a) We could make the logic of every test element more complicated, and force every plugin to implement support for "dynamic enable" b) We could rewrite the user-provided test plan into a suitable format for execution using the currently available operators It turns out, that "dynamic enable" can be represented with the currently existing IfComponent. In that regard, we add a lowering that transforms "component with a possibly complex enabled condition" into a couple of existing components: IfController and a component with a trivial enabled=true condition. Then "backend" (==executor) don't even need to know there are "conditionally disabled elements". The engine can already execute IfControllers just fine. Of course, the approach with transforming the plan might fail in certain cases (e.g. how should ThreadGroup with dynamic disable should even work?!) However, I really see no value in going with option "a". Vladimir
