Which would you rather do: manually write out xml for every class that JMeter searches for, or
type "ant class_config" ? I know what I'd rather do. I'm not disagreeing with you, I'm just expanding on your idea, really. -Mike On 4 Feb 2003 at 21:21, Oliver Rossmueller wrote: > Mike Stover wrote: > > How about making a little utility that will generate an XML config file by reading >the > > jars (like currently), and then JMeter will just read this xml at startup? Then, >at any > > time, one can run the script, or hit a button, and JMeter will re-generate this >config > > file and reload, thus allowing developers to drop their jars in and go? JMeter >could > > even update itself on the fly, and startup should be quicker too. > > That's a possibility. But we know about all the GUI classes we have in > JMeter so why have JMeter search for them? I think it is not hard to > manually maintain a list of the classes - XML file/properties > file/plugins/... - and read the list at startup. And to search for > additional classes in lib/ext should not take too long because there > should not be millions of them. > > Oliver > > > > > > -Mike > > > > On 3 Feb 2003 at 23:50, Oliver Rossmueller wrote: > > > > > >>I would like to get rid of the way JMeter is walking through all the > >>jars in lib/ext searching for GUI classes. On my machine (AMD Duron > >>800MHz) it takes 15 seconds from starting JMeter until the JMeter window > >>shows up which is quite annoying. I played around with what I called > >>plugins on the refactorings branch to speed this up. The way it is done > >>is not to search for classes in the jars but to register all known > >>JMeter GUI classes explicitly. Because JMeter is seperated into 7 jars I > >>needed a way to register the classes jar by jar and therefore added a > >>class to each of the jars which implements a Plugin interface and has > >>the responsibility to register all relevant classes. This is far from > >>being perfect but this way it takes only 7 seconds to start JMeter. This > >>is still too much but I know there is room for further improvement. > >> > >>I would like to implement the plugins on the main branch now in the > >>following way: > >> > >>- I make plugins out of the seven JMeter jars to register all the JMeter > >>classes explicitly > >>- therefore I would move the jars from lib/ext to a new plugin directory > >>- the mechanism to search all jars in lib/ext for GUI classes would > >>remain to make it easy for others to add their additional elements/GUIs > >>to JMeter without the need to worry about plugins (I assert that these > >>add-on jars will be small and therefore fast to search for classes) > >> > >>Opinions, objections, improvements? > >> > >>Oliver > >> > > > > > > > > > > -- > > Michael Stover > > [EMAIL PROTECTED] > > Yahoo IM: mstover_ya > > ICQ: 152975688 > > AIM: mstover777 > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > -- Michael Stover [EMAIL PROTECTED] Yahoo IM: mstover_ya ICQ: 152975688 AIM: mstover777 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
