Gordon Sim wrote:
Alan Conway wrote:
Don't forget there are *two* points for centralizing test control
code. One is the co-ordinator, the other is the test runners that
will actually be running the tests.
My view is that anything that can be done in the co-ordinator should
be done there. The test runners only centralize code for one language;
the co-ordinator centralizes code for the entire framework.
Agreed, but some things can only be done locally - e.g. checking
timeouts, capturing failure messages.
https://issues.apache.org/jira/browse/QPID-406 proposes an
interceptor/handler framework for the timeout issue, comments
.appreciated. From past experience I can attest that this is an
extremely powerful pattern. E.g. the existing C++ logging code could be
rewritten as a pair of Frame interceptors and shared between client and
broker. The C++ 0-9 request/response logic is effectively a pair of
interceptors. Management instrumentation could be written as interceptors.
There are 2 big payoffs from formalising this stuff as interceptors
1. You can *configure* behavior rather than coding it. Instead of
having a bunch of "if (debug) log(debugmsg)", "if (managementOn)
issue(managementInfo)" on the call path you build a chain of
interceptors that reflects what you want. The core just calls the first
one, the last one calls back into the core. The core doesn't need to
know anything about logging, management etc. etc.
2. You can do plug ins, and dynamically extend behaviour at runtime
*without even having access to core source code.* Even in the open
source world this really lowers the barrier of entry to people who want
to contribute to or experiment with qpid they can write plugins, test
and use them without ever getting commit rights to change the core.
Comments to the list or on the JIRA, I think this is a worthwhile
direction to go in. We can start with just enough for the interop test
use case and extend as we go.
Cheers,
Alan.
