I doubt it would affect JMeter's test-run performance much. It might possibly result in a small delay at the start of a test run. It would also likely help us improve support for distributed JMeter - which would help JMeter scale up.
-Mike > -----Original Message----- > From: Jamie Davidson [mailto:[EMAIL PROTECTED]] > Sent: Thursday, March 21, 2002 8:05 AM > To: 'JMeter Developers List' > Subject: RE: using Avalon > > > Any ideas on how this change would affect the overall performance of > JMeter? > And - BTW - who gets to vote? - if it means anything, +1. > > -----Original Message----- > From: Boutcher, James K. [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, March 19, 2002 11:26 AM > To: JMeter Developers List > Subject: RE: using Avalon > > > Sorry for taking so long - had to find the time to check it out.. > > +1 > > -----Original Message----- > From: kevin hammond [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, March 19, 2002 6:48 AM > To: JMeter Developers List > Subject: Re: using Avalon > > > I vote +1 for moving JMeter to use the Avalon > architecture. > > Thanks, > Kevin Hammond > > --- kevin hammond <[EMAIL PROTECTED]> wrote: > > Hi, > > > > I will send in my vote this weekend after reading > > more > > about the Avalon architecture. > > > > Mike, do you have any guesstimates on how long the > > conversion would take? Weeks? Months? > > > > We really need to create at least one branch. > > Always > > working off the mainline is one of the reasons we > > cannot get a new release out. People keep checking > > in > > brand new code/functionality. > > > > Thanks, > > Kevin > > > > --- Berin Loritsch <[EMAIL PROTECTED]> wrote: > > > Stover, Michael wrote: > > > > Hi all, > > > > Berin has convinced me that using the > > > Avalon-Excalibur framework in > > > > JMeter would be helpful. I'd like to know if > > > everyone is agreeable to > > > > letting me rework JMeter's structure to do this. > > > > > > > > to be specific, it will require changing the > > > interfaces (such as > > > > JMeterComponentModel and ModelSupported, > > Saveable, > > > etc). The way new > > > > components would be written would change (the > > idea > > > is to make is easier and > > > > more consistent). > > > > > > > > I think the benefits of this would be: > > > > 1. Simpler and more consistent process to create > > > new components > > > > 2. Remove dependence on Swing in non-gui classes > > > > 3. Better design resulting in easier to manage > > and > > > less buggy code > > > > 4. Possibly more flexibility in the types of > > > components JMeter handles > > > > (right now there's a rigid and somewhat > > arbitrary > > > categorization of > > > > components as "timers", "listeners", "config > > > elements", "logic controllers", > > > > and "generative controllers". "Assertions" and > > > "Modifiers" were new > > > > elements that have been tacked on. Using > > Avalon, > > > the organization of > > > > existing and new elements would be much more > > > flexible. > > > > > > All of those are good. > > > > > > Other examples of Avalon based projects include: > > > Apache Cocoon > > > Apache JAMES > > > FOP > > > > > > > > > > > Only fair to list what I see are the > > > disadvantages: > > > > 1. Lot's of work that will delay many new > > features > > > everyone wants > > > > (cut/copy/paste, better reports/visualizers, > > etc). > > > > 2. Work that may interfere with what you are > > > working on currently > > > > > > These disadvantages can be taken care of in a way > > > that we are modular > > > about what we are doing at any one time. > > > > > > > > > > > And, the risks: > > > > 1. May introduce complexity for relatively > > little > > > gain. Berin probably > > > > doesn't see this as a risk, cause he is > > > comfortable with Avalon. It looks > > > > pretty good to me, but I see the potential that > > > the new abstractions may > > > > confuse things, and not produce as much benefit > > as > > > I think. Obviously, I've > > > > decided this risk is small, but others may not > > > think so. > > > > > > It actually reduces complexity. Currently, the > > > JMeter code is fairly > > > convoluted and difficult to follow. By adhering > > to > > > the principles of > > > Component Oriented Programming, the system can > > grow > > > in a healthy manner > > > that is flexible and easy to follow. > > > > > > We also gain the ability to use the test harnesses > > > to provide sanity > > > checks before release. > > > > > > > > > > > Perhaps a branch could be made for this work. > > I'd > > > rather avoid that though, > > > > if possible. > > > > > > > > Any thoughts? > > > > > > > > > I am +1 (of course) > > > > > > As to the branch question, you will have to answer > > > that based on how you > > > feel that would manage the risk of the conversion. > > > > > > If you have any questions I will be happy to > > answer > > > them. > > > > > > > > > -- > > > > > > "They that give up essential liberty to obtain a > > > little temporary safety > > > deserve neither liberty nor safety." > > > - Benjamin Franklin > > > > > > > > > -- > > > To unsubscribe, e-mail: > > > <mailto:[EMAIL PROTECTED]> > > > For additional commands, e-mail: > > > <mailto:[EMAIL PROTECTED]> > > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Yahoo! Sports - live college hoops coverage http://sports.yahoo.com/ > > > > -- > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Sports - live college hoops coverage http://sports.yahoo.com/ > > -- > 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]> > > > -- > 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]>
