currently the ContextManger class instantiated twice during the ExecTool constructor invocation.
This happens because (see comments with "***" marker):

    private ExecTool(ExecToolManager mgr, InterviewParameters interviewParams, Map map) {
        super(mgr, "exec", "browse.window.csh");

// ..... [skip]

        if (this.interviewParams != null) {
            // *** this initializes the 'context' field:
            this.interviewParams.setTemplateManger(this.getContextManager());
        }

// ..... [skip]

// *** this nulls the 'context' field again since
        // the first line of the #initGUI() method contains code "context = null;"
        initGUI(map);
    }


this behaviour causes some model inconsistancy to happen in the very early stage
since the "interviewParameters" object gets loaded with the 1st instance of ContextManager object that is no longer used, and the 2nd instance of the ContextManager is used further.

If there were no specific reason to have code
    private void initGUI(Map map) {
        context = null;
// ...
, i suggest to remove this line.

Anyway, all interview objects created within one ContextManager must refer to that ContextManager instance, but not to some other one.


Same problem in method
ExecTool#init(TestSuite,WorkDirectory) :

    private void init(TestSuite newTestSuite, WorkDirectory newWorkDir)
            throws TestSuite.Fault, Interview.Fault {
        context = null;
// ...

does that made intentionally?
if yes, please explain what is the idea?

The problem is generic object identification design logic: if our subclass of ContextManager stores some data that are bound exactly to this object instance, sparadical creation of a new object breaks this logic completely: new object will not contain the data that were stored in the previous object.

So, the lifecycle and the representative responsibilities of the ContextManager class must be defined by the JT API:
when this class gets instantiated?
What entity it does represent?
When it dies (with possibly #dispose() call)?
Our current vision was that the ContextManager class represents a TestSuite _opened_in_a_certain_JT_tab_ . Is that correct?
If yes, why the new ContentManager instances created for the same testsuite and the same tab?