> -----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
> 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.
But this neglects the issue of who had to create the configuration
element/XML with the correct ingredients. In my thinking, your example is
very useful if we're talking about an object saving itself to XML, and then
recreating itself from that same XML, because in that case, only the object
is required to know it's own XML format.
For external objects trying to configure the Component, it is no simpler to
generate correct XML than it is to correctly use a Java interface.
Consider in JMeter, the GUI objects have to create test elements. Would it
make sense for the gui objects to create XML, or configuration objects,
which is then used to configure test elements, or, have the GUI objects
configure the test elements by calling appropriate methods on those
elements? I vote for the latter, if only because it is what Java Developers
expect to have to learn.
-Mike
>
> --
> 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]>
