> -----Original Message----- > From: Stover, Michael [mailto:[EMAIL PROTECTED]] > > 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.
That's a good summary. It is more important to understand the principles that Avalon is built with than the jars themselves. > 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. Absolutely. > 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). 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. > 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)? That sounds good. The new source tree should be separate from the current source so that there is no confusion. > > > -----Original Message----- > > From: Dan Kegel [mailto:[EMAIL PROTECTED]] > > 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:[EMAIL PROTECTED]> > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > -- > To unsubscribe, e-mail: > <mailto:jmeter-dev-> [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]>
