I'm wondering if we're disagreeing over a difference of context. I understand that when you say "Component", you do not mean the same thing that I mean when I think it. You, I think, are referring to something much more active, almost a service type of thing. Whereas, what I am thinking of, you would call merely "data".
However, what I'm seeing is that the idea of Component lifecycle can be applied beyond just your idea of Components. The test elements of JMeter may not be full-fledged Components, but they nevertheless go through a well-defined lifecycle, and I am beginning to see how some of the design ideas of Avalon can help even there. Perhaps that makes more sense? -Mike > -----Original Message----- > From: Berin Loritsch [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, March 27, 2002 1:51 PM > To: 'JMeter Developers List' > Subject: RE: Using Avalon > > > > -----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]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
