第1页 / 共16页
第2页 / 共16页
第3页 / 共16页
第4页 / 共16页
第5页 / 共16页
第6页 / 共16页
第7页 / 共16页
第8页 / 共16页
jmeter源码介绍 二次开发参考.pdf
How to Write a plugin for JMeter
Authors
Mike Stover, Peter Lin
Revision 1.1 November 2005
Copyright Apache
Table of Contents
Basic structure of JMeter.................................................................................................3
Writing a Visualizer........................................................................................................ 5
GraphListener..................................................................................................................8
ItemListener.....................................................................................................................8
Writing Custom Graphs.................................................................................................. 8
Making a TestBean Plugin For Jmeter..........................................................................10
Building JMeter.............................................................................................................14
How to write a plugin for JMeter
Introduction from Peter Lin
On more than one occasion, users have complained JMeter's developer documentation is out of
date and not very useful. In an effort to make it easier for developers, I decided to write a simple
step-by-step tutorial. When I mentioned this to mike, he had some ideas about what the tutorial
should cover.
Before we dive into the tutorial, I'd like to say writing a plugin isn't necessarily easy, even for
someone with several years of java experience. The first extension I wrote for JMeter was a
simple utility to parse HTTP access logs and produce requests in XML format. It wasn't really a
plugin, since it was a stand alone command line utility. My first real plugin for JMeter was the
webservice sampler. I was working on a .NET project and needed to stress test a webservice.
Most of the commercial tools out there for testing .NET webservices suck and cost too much.
Rather than fork over several hundred dollars for a lame testing tool, or a couple thousand dollars
for a good one, I decided it was easier and cheaper to write a plugin for JMeter.
After a two weeks of coding on my free time, I had a working prototype using Apache Soap driver.
I submitted it back to JMeter and mike asked me if I want to be a committer. I had contributed
patches to Jakarta JSTL and tomcat in the past, so I considered it an honor. Since then, I've
written the access log sampler, Tomcat 5 monitor and distribution graph. Mike has since then
improved the access log sampler tremendously and made it much more useful.
Introduction from Mike Stover
One of my primary goals in designing JMeter was to make it easy to write plugins to enhance as
many of JMeter's features as possible. Part of the benefit of being open-source is that a lot of
people could potentially lend their efforts to improve the application. I made a conscious decision
to sacrifice some simplicity in the code to make plugin writing a way of life for a JMeter developer.
While some folks have successfully dug straight into the code and made improvements to JMeter,
a real tutorial on how to do this has been lacking. I tried a long time ago to write some
documentation about it, but most people did not find it useful. Hopefully, with Peter's help, this
attempt will be more successful.
Basic structure of JMeter
JMeter is organized by protocols and functionality. This is done so that developers can build new
jars for a single protocol without having to build the entire application. We'll go into the details of
building JMeter later in the tutorial. Since most of the jmeter developers use eclipse, the article will
use eclipse directory as a reference point.
Root directory - /eclipse/workspace/jakarta-jmeter/
jakarta-jmeter
• bin – contains the .bat and .sh files for starting Jmeter. It also contains ApacheJMeter.jar and
properties file
• docs – directory contains the JMeter documentation files
• extras – ant related extra files
•
•
•
•
•
lib – contains the required jar files for Jmeter
lib/ext – contains the core jar files for jmeter and the protocols
src – contains subdirectory for each protocol and component
test – unit test related directory
xdocs – Xml files for documentation. JMeter generates documentation from Xml.
As the tutorial progresses, an explanation of the subdirectories will be provided. For now, lets
focus on “src” directory. From the screen capture, we see the following directories.
Src
components – contains non-protocol-specific components like visualizers, assertions, etc..
•
core – the core code of JMeter including all core interfaces and abstract classes.
•
• examples – example sampler demonstrating how to use the new bean framework
•
• htmlparser – a snapshot of HtmlParser, donated by HtmlParser project on sourceforge
•
• monitor – tomcat 5 monitor components
• protocol – contains the different protocols JMeter supports
jorphan – utility classes providing common utility functions
functions – standard functions used by all components
Within “protocol” directory, are the protocol specific components.
ftp – components for load testing ftp servers
Protocol
•
• http – components for load testing web servers
•
•
•
•
• mail – components for load testing mail servers
tcp – components for load testing TCP services
•
java – components for load testing java components
jdbc – components for load testing database servers using jdbc
jndi – components for load testing jndi
ldap – components for load testing LDAP servers
As a general rule, all samplers related to HTTP will reside in “http” directory. The exception to the
rule is the Tomcat5 monitor. It is separate, because the functionality of the monitor is slightly
different than stress or functional testing. It may eventually be reorganized, but for now it is in its
own directory. In terms of difficulty, writing visualizers is probably one of the harder plugins to
write.
Jmeter Gui – TestElement Contract
When writing any Jmeter component, there are certain contracts you must be aware of – ways a
Jmeter component is expected to behave if it will run properly in the Jmeter environment. This
section describes the contract that the GUI part of your component must fulfill.
GUI code in Jmeter is strictly separated from Test Element code. Therefore, when you write a
component, there will be a class for the Test Element, and another for the GUI presentation. The
GUI presentation class is stateless in the sense that it should never hang onto a reference to the
Test Element (there are exceptions to this though).
A gui element should extend the appropriate abstract class provided:
AbstractSamplerGui
AbstractAssertionGui
AbstractConfigGui
AbstractControllerGui
AbstractPostProcessorGui
AbstractPreProcessorGui
AbstractVisualizer
AbstractTimerGui
These abstract classes provide so much plumbing work for you that not extending them, and
instead implementing the interfaces directly is hardly an option. If you have some burning need to
not extend these classes, then you can join me in IRC where I can convince you otherwise :-).
So, you've extended the appropriate gui class, what's left to do? Follow these steps:
1. Implement getResourceLabel()
1. This method should return the name of the resource that represents the title/name of the
component. The resource will have to be entered into Jmeters messages.properties file
(and possibly translations as well).
2. Create your gui. Whatever style you like, layout your gui. Your class ultimately extends
Jpanel, so your layout must be in your class's own ContentPane. Do not hook up gui elements
to your TestElement class via actions and events. Let swing's internal model hang onto all the
data as much as you possibly can.
1. Some standard gui stuff should be added to all Jmeter gui components:
border
1. call setBorder(makeBorder()) for your class. This will give it the standard Jmeter
2. add the title pane via makeTitlePanel(). Usually this is the first thing added to your
gui, and should be done in a Box vertical layout scheme, or with Jmeter's VerticalLayout
class. Here is an example init() method:
private void init()
{
setLayout(new BorderLayout());
setBorder(makeBorder());
Box box = Box.createVerticalBox();
box.add(makeTitlePanel());
box.add(makeSourcePanel());
add(box,BorderLayout.NORTH);
add(makeParameterPanel(),BorderLayout.CENTER);
}
3.
Implement public void configure(TestElement el)
1. Be sure to call super.configure(e). This will populate some of the data for you, like
2. Use this method to set data into your gui elements. Example:
the name of the element.
public void configure(TestElement el)
{
super.configure(el);
useHeaders.setSelected(el.getPropertyAsBoolean
(RegexExtractor.USEHEADERS));
useBody.setSelected(!el.getPropertyAsBoolean
(RegexExtractor.USEHEADERS));
regexField.setText(el.getPropertyAsString
(RegexExtractor.REGEX));
templateField.setText(el.getPropertyAsString
(RegexExtractor.TEMPLATE));
defaultField.setText(el.getPropertyAsString
(RegexExtractor.DEFAULT));
matchNumberField.setText(el.getPropertyAsString
(RegexExtractor.MATCH_NUM));
refNameField.setText(el.getPropertyAsString
(RegexExtractor.REFNAME));
}
implement public void modifyTestElement(TestElement e). This is where you
move the data from your gui elements to the TestElement. It is the logical reverse of the
previous method.
1. Call super.configureTestElement(e). This will take care of some default data for
2. Example:
you.
public void modifyTestElement(TestElement e)
{
super.configureTestElement(e);
e.setProperty(new BooleanProperty
(RegexExtractor.USEHEADERS,useHeaders.isSelected()));
e.setProperty
(RegexExtractor.MATCH_NUMBER,matchNumberField.getText
());
if(e instanceof RegexExtractor)
{
RegexExtractor regex = (RegexExtractor)e;
regex.setRefName(refNameField.getText());
regex.setRegex(regexField.getText());
regex.setTemplate(templateField.getText());
regex.setDefaultValue(defaultField.getText());
}
}
implement public TestElement createTestElement(). This method should create a
new instance of your TestElement class, and then pass it to the modifyTestElement
(TestElement) method you made above.
4.
5.
public TestElement createTestElement()
{
RegexExtractor extractor = new RegexExtractor();
modifyTestElement(extractor);
return extractor;
}
The reason you cannot hold onto a reference for your Test Element is because Jmeter reuses
instance of gui class objects for multiple Test Elements. This saves a lot of memory. It also
makes it incredibly easy to write the gui part of your new component. You still have to struggle
with the layout in Swing, but you don't have to worry about creating the right events and actions for
getting the data from the gui elements into the TestElement where it can do some good. Jmeter
knows when to call your configure, and modifyTestElement methods where you can do it in a very
straightforward way.
Writing Visualizers is somewhat of a special case, however.
Writing a Visualizer
Of the component types, visualizers require greater depth in Swing than something like
controllers, functions or samplers. You can find the full source for the distribution graph in
“components/org/apache/jmeter/visualizers/”. The distribution graph visualizer is divided into two
classes.
• DistributionGraphVisualizer – visualizer which Jmeter instantiates
• DistributionGraph – Jcomponent which draws the actual graph
The easiest way to write a visualizer is to do the following:
1. extend org.apache.jmeter.visualizers.gui.AbstractVisualizer
2.
implement any additional interfaces need for call back and event notification. For example, the
DistributionGraphVisualizer implements the following interfaces:
1.
2.
ImageVisualizer
ItemListener – according to the comments in the class, ItemListener is out of date and isn't
used anymore.
3. GraphListener
4. Clearable
AbstractVisualizer provides some common functionality, which most visualizers like “graph
results” use. The common functionality provided by the abstract class includes:
•
configure test elements – This means it create a new ResultCollector, sets the file and sets the
error log
create the stock menu
•
• update the test element when changes are made
•
•
create a file panel for the log file
create the title panel
In some cases, you may not want to display the menu for the file textbox. In that case, you can
override the “init()” method. Here is the implementation for DistributionGraphVisualizer.
1 /**
2 * Initialize the GUI.
3 */
4 private void init()
5 {
6 this.setLayout(new BorderLayout());
7
8 // MAIN PANEL
9 Border margin = new EmptyBorder(10, 10, 5, 10);
10
11 this.setBorder(margin);
12
13 // Set up the graph with header, footer, Y axis and graph display
14 JPanel graphPanel = new JPanel(new BorderLayout());
15 graphPanel.add(createGraphPanel(), BorderLayout.CENTER);
16 graphPanel.add(createGraphInfoPanel(), BorderLayout.SOUTH);
17
18 // Add the main panel and the graph
19 this.add(makeTitlePanel(), BorderLayout.NORTH);
20 this.add(graphPanel, BorderLayout.CENTER);
21 }
The first thing the init method does is create a new BorderLayout. Depending on how you want to
layout the widgets, you may want to use a different layout manager. Keep mind using different
layout managers is for experts.
The second thing the init method does is create a border. If you want to increase or decrease the
相关推荐
2023年江西萍乡中考道德与法治真题及答案.doc
2012年重庆南川中考生物真题及答案.doc
2013年江西师范大学地理学综合及文艺理论基础考研真题.doc
2020年四川甘孜小升初语文真题及答案I卷.doc
2020年注册岩土工程师专业基础考试真题及答案.doc
2023-2024学年福建省厦门市九年级上学期数学月考试题及答案.doc
2021-2022学年辽宁省沈阳市大东区九年级上学期语文期末试题及答案.doc
2022-2023学年北京东城区初三第一学期物理期末试卷及答案.doc
2018上半年江西教师资格初中地理学科知识与教学能力真题及答案.doc
2012年河北国家公务员申论考试真题及答案-省级.doc
2020-2021学年江苏省扬州市江都区邵樊片九年级上学期数学第一次质量检测试题及答案.doc
2022下半年黑龙江教师资格证中学综合素质真题及答案.doc
