This page describes the main JMeter pieces: the GUI, the test tree (aka Test Plan), the Engine,... and how they relate to each other.
PLEASE NOTE THIS PARTICULAR PART OF JMETER'S ARCHITECTURE IS CURRENTLY BEING HEAVILY MODIFIED BY OLIVER ROSSMUELLER. (2003-01-08)- I would like to know more about exactly what you are doing before you commit. As I said in email, I don't think what you are doing should be all that complicated. - MikeStover
It did not look that complicated when I started but I could not resist to change and clean up stuff while I was walking through the code. It is like a chain reaction: at first I just wanted to implement cut/copy/paste and now I'm in the middle of nowhere. Don't get me wrong, I'm not lost in the dark, I know where I am, where I have to go and what I have to do, but it will take some time. To let you know where I am at the moment I added a section below where I will describe what I've done so far and what I will do the next time. -- OliverRossmueller
What will you do if the rest of the developers like some of the changes, but not others? Having it all wrapped up in one great lump in a separate branch is not going to work well. If I were you, I'd stop and start the discussion of these things, because it may turn out your wasting your time. I can tell you now there's several things I strongly disagree with in your list below. -MikeStover
Refactoring = changing the the intern organisation without changing the behavior! Why do you add features? -- JörgWeinmann
Each node in the test tree is currently represented by a JPanel -- shown on the right side of the interface when you select that node.
These JPanel objects are created as you build the test plan (or all in a shot if you load a test plan from scratch) -- this causes performance concerns (both in terms of time and memory).
Those JPanels implement the JMeterGUIComponent interface. The most relevant method defined by this interface is the createTestElement() method -- which will create a Test Element from the values held by the GUI.
The Engine takes that tree and compiles and runs it. See JMeterTestExecution for more info.
Open questions:
Who invokes createTestElement()? The engine? Also when the tree needs to be saved to disk? - Answer: The Actions control this behavior. Start.java queries the JMeterTreeModel for the TestTree, and then converts it into TestElements via an inherited method (inherited because other actions use it to). See AbstractAction.java.
Are test elements also created and used to populate the GUI when a test plan is loaded from disk? - Answer: Yes, the process goes in reverse here. GUI objects are populated with information from the TestElements via their configure(TestElement) method.
mapping from old to new property names necessary to load .jmx files -> proof of concept exists, has to be implemented for all test elements
internal reorganisation makes it almost impossible to write .jmx files that are compatible with JMeter 1.8 -> introduced a new file format, save is implemented as proof of concept, load has still to be done