jakarta-jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stover, Michael" <Michael.Sto...@usa.xerox.com>
Subject RE: Using Avalon
Date Wed, 27 Mar 2002 17:24:27 GMT
I guess I'll weigh in on this topic....

The Avalon framework appears to me to be a collection of interfaces, and a
suggested design philosophy that essentially talks about the lifecycle of
certain types of objects (called Components).  What I have gained thus far
from my study of Avalon is the idea that Components of you program can be
made simpler to understand by rigorously defining their lifecycle via
interfaces, and enforcing those lifecycle events in the containers that hold
the Components.  Further, different implementations of the Components can
implement different lifecycle interfaces, and by doing so they can control
how they are used to some extent.  It is also useful to separate in one's
mind, and in the code, interfaces that have to do with work to be done, and
interfaces that have to do with the Component's lifecycle.

The advantage, in terms of JMeter's use, is that extending JMeter will
become simpler to understand.  Developers will have access to documentation
that explicitly defines the work interface, and each lifecycle interface,
and what the purposes of each are.  

Also, in my view, the lifecycle interfaces defined in the Avalon framework
may or may not be useful as is to JMeter.  I'm currently thinking that
JMeter may want to define it's own lifecycle interfaces (for instance, there
are two separate times when JMeter clones test objects - once for each
thread, and once for each individual sample request.  However, for many
objects, these two cloning events are unneccessary, and for others, both are
necessary, and for still others, only one of the other are necessry.  These
could be two lifecycle interfaces that developers would choose to implement
or not, thus defining the behavior for their extension).

In any event, nothing has yet been decided.  I currently see no benefit to
using the Avalon Framework jar, but I see great benefits to using the ideas
of Avalon (Excalibur is another issue that I'm ignoring here).

That said, I'm still working on the conversion of JMeter's design to
separate gui and non-gui.  It's getting ugly, and I apologize that I'm
unable to do it piecemeal.  I would like to check it in and ask for help
from people, but certain parts won't compile (I'm avoiding the EJB stuff as
it is complicated code, and I have no background in EJB's - I'm hoping Neth
can help there).  Would people be opposed to seeing this stuff in CVS?
Should I create a new alternative source directory for this work to go into
(this seems best to me)?

-Mike

> -----Original Message-----
> From: Dan Kegel [mailto:dank@kegel.com]
> Sent: Wednesday, March 27, 2002 12:18 PM
> To: JMeter Developers List
> Subject: Re: Using Avalon
> 
> 
> Berin Loritsch wrote:
> > You can't understand a framework until you understand what
> > the thought processes are in that framework.  Before I
> > started writing most of that documentation, we kept answering
> > the same questions over and over again.  Guess what!  The
> > documentation represents the type of questions we had to
> > answer.  
> 
> However, it appears to have usability problems.  Try this
> experiment: have someone who knows Java but not Avalon
> look at the Avalon web page, and ask them to build a
> demo program using Avalon.  IMHO this should take no
> longer than five minutes, including them figuring out
> how to download Avalon and the demo.
> I tried exactly this, and after half an hour, gave up.
> 
> Concrete problems:
> 1. http://jakarta.apache.org/avalon/ has no 'Download' link.
> 
> 2. The description of Framework is misleading:
>    "The framework is not a product or an API set or a set of
>     interfaces: it is a collection of code design patterns, rules, 
>     guidelines and suggestions on how to write software that plugs
>     into the framework."
>    If that's the case, I would expect Framework to be named 
> Documentation,
>    and contain no code.  Yet there is lots of code in Framework.
> 
> 3. The demo FTP server is apparantly in 'Cornerstone', but the 
>    'Download' link at http://jakarta.apache.org/avalon/cornerstone/ 
>    is broken or points to an empty directory.
> 
> 4. There is no simple, step-by-step example showing how to 
>    download and build a sample app, from start to finish.
>    Instead, I find a large number of wordy web pages that 
>    talk on and on about how wonderful Avalon is, without actually
>    giving me any concrete assistance in getting started.
> 
> Now, I'd love to benchmark that demo FTP server, and give the Avalon
> folks some feedback about their performance, but I'm stymied; it
> was just too hard.  This whole experience has made me very skeptical
> about Avalon actually being usable by someone who is not part
> of the Avalon team.  Hence my suprise when I saw that JMeter was
> considering using it.  When I realized the person who got them
> to consider it was on the Avalon team, it made a lot more sense.
> 
> IMHO the JMeter team should assess the usability of Avalon 
> before jumping headfirst into using it.
> 
> Fix #3 and #4, and I will be more than happy to help the Avalon
> folks by stress-testing their demo apps.
> 
> - Dan
> 
> --
> To unsubscribe, e-mail:   
> <mailto:jmeter-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: 
> <mailto:jmeter-dev-help@jakarta.apache.org>
> 

--
To unsubscribe, e-mail:   <mailto:jmeter-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:jmeter-dev-help@jakarta.apache.org>


Mime
View raw message