> -----Original Message-----
> From: Stover, Michael [mailto:[EMAIL PROTECTED]]
>
> > I would encourage the use of predefined lifecycle
> interfaces and the
> > configuration/parameters objects as they make life simpler when you
> > want to use the same component outside of JMeter. You
> don't need to
> > use all of them, but they are there if you need it. They
> are called
> > in a defined order, and keeping that order consistent
> across projects
> > helps make it easier to learn a new system.
>
> The problem I have with the predefined lifecycle interfaces
> of Avalon is that many of them use typeless data objects.
> Configuration, for instance, passes DOM trees around. Why is
> it preferable to pass data as DOM trees rather than as normal
> Java Objects?
Actually it is not a DOM tree. It is a hierarchical configuration
element that only lets you iterate down the list (not up).
When you are referring to configure() or configuring a component,
it is easier to work with a known generic configuration element
than it is to reinvent the wheel and force the developer to write
bean and mapper logic.
Consider this scenario:
Our configuration is in XML (nothing new here), and we have
several URL Samples:
<sampler type="http">
<host address="localhost" secure-port="443" port="80"/>
<url secure="false" path="index.html" method="POST"/>
<url secure="true" path="test.html" method="POST"/>
</sampler>
Instead of creating a "bean" object, you can gain *type_safe*
information
while allowing default values with the configuration object.
Avalon already has the code to convert XML to and from configuration
objects--preserving namespaces if necessary. Now all you have to do
in the portion of code that reads the Configuration object is to use
the utility class to read the information in and pass the tree portions
to the proper components:
Configuration[] samplerConfigs = mainConf.getChildren("sampler");
for (int i = 0; i < samplerConfigs.length; i++)
{
Sampler sampler = createSampler(
samplerConfigs[i].getAttribute("type") );
sampler.configure( samplreConfigs[i] );
this.samplers.add(sampler);
}
In the sampler configuration portion, you write something along these
lines
(assuming you are only testing one host per sampler--not unreasonable):
configure( Configuration conf )
{
Configuration hostConf = conf.getChild("host");
Configuration[] uris = conf.getChildren("url");
this.secure = new InetAddress( hostConf.getAttribute("address",
"localhost"),
hostConf.getAttributeAsInteger("secure-port", 443)
);
this.normal = new InetAddress( hostConf.getAttribute("address",
"localhost"),
hostConf.getAttributeAsInteger("port", 80)
);
String uribase = "http://"; + this.normal.toString();
String suribase = "https://"; + this.secure.toString();
for (int I = 0; I < uris.length; I++)
{
String uri = uris[I].getAttribute("method", "GET") + "|";
if ( uris[I].getAttributeAsBoolean("secure", false) )
{
uri += suribase;
}
else
{
uri += uribase;
}
uri += uris[I].getAttribute("path");
}
}
Notice that if you need integers, longs, floats, doubles, or booleans,
all are possible.
Using the configuration elements makes the system easier to build as you
don't have the added complexity that comes with registering data mappers
with the component types. Each component handles how it interprets the
config element as it wants.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
