Simply creating ConfigTestElement objects is perfectly legit. Whoever wrote FTPConfig and TCPConfig may have thought they were necessary when they started, but learned otherwise as they went and maybe just never deleted them.
If there's no custom logic whatsoever in your config class, using ConfigTestElement is the way to go. -Mike On Wed, 2005-04-27 at 02:28 +0100, sebb wrote: > There's also some strangeness in the FTPConfigGui and TCPConfigGui > classes - they just create a generic ConfigTestElement instead of the > corresponding FTPConfig or TCPConfig class. > > So it looks like the FTPConfig and TCPConfig classes are not being > used at present... > > S. > On 4/26/05, Michael Stover <[EMAIL PROTECTED]> wrote: > > It seems my email didn't make it to the list or something. > > > > To me, it looks like you have a disconnect between your various > > elements, with some using static strings from JMSSampler for property > > name values and some using BaseJMSSampler strings. I suggest choosing > > one place to hold your static strings and use them everywhere. The > > properties may be getting written into your samplers, but attached to an > > unexpected property name. > > > > -Mike > > > > > > On Tue, 2005-04-26 at 00:27 +0100, sebb wrote: > > > On 4/25/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > > > > > > I'm the one responsible for the JMS Queue Sampler (Messaging Request). > > > > To accomodate the retrieval of ConnectionFactories and queues i made a > > > > separate screen JndiDefaultsGui to provide the correct parameters for > > > > the InitialContext. I posted on this news group how the > > > > default-mechanism works, but I have not gotten any reply yet. > > > > > > > > I can not find any documentation on how to make this work: having a > > > > default screen with properties (x, y, z) and the sampler screen with > > > > some of the same properties (x, y). How does JMeter support that if the > > > > user does not fill in the properties on the sampler screen, the > > > > properties of the default (configuration) screen are used. > > > > > > This is done by setting the appropriate properties in the Config element. > > > > > > The Sampler element then uses these as defaults. This is handled > > > automatically if you extend the appropriate class. > > > > > > For a fairly simple example, have a look at TCPConfig and TCPSampler. > > > TCPSampler defines the property names. TCPConfig uses these to set the > > > properties from its screen. > > > > > > Of course one does not have to define a Config element, especially if > > > the Sampler has very few input fields. > > > > > > > I know the QueueSampler is not ready yet, but I have had some setback > > > > when my laptop was ripped. Have to wait for a new one now. > > > > > > > > Any comments are welcome and I will change the code if necessary. > > > > > > > > Sebb: can u elaborate on what the correct setup would be? > > > > > > See above. > > > > > > It's also vital to extend the appropriate JMeter class (or the > > > relevant interface) as the Menu system depends on these to decide > > > where to put each class when it is creating the menu structure. The > > > JMeter runtime engine also depends on classes having the correct > > > parent or interface(s). > > > > > > > Greetings, > > > > > > > > Martijn > > > > > > > > > > > > > Three, surely? > > > > > > > > > > > > > > > JMS Publisher > > > > > JMS Subscriber > > > > > Messaging Request > > > > > > > > > > > > > > > Not sure how they relate to each other - some documentation for > > > > > component_reference would be useful ;-) > > > > > > > > > > S. > > > > > On 4/24/05, Peter Lin <[EMAIL PROTECTED]> wrote: > > > > > > > > > >> There's two samlers. the topic sampler which I wrote and the queue > > > > >> sampler written by martijn. the topic sampler i wrote doesn't use a > > > > >> configuGUI. I think it's part of the queue sampler. > > > > >> > > > > >> peter > > > > >> > > > > >> > > > > >> On 4/24/05, sebb <[EMAIL PROTECTED]> wrote: > > > > >> > > > > >>> The JMS protocol files seem to be set up a bit differently from most > > > > >>> of the others. > > > > >>> > > > > >>> For example, the file JMSConfigGui is in control.gui and not > > > > >>> config.gui. It also extends JPanel, rather than one of the JMeter > > > > >>> GUI > > > > >>> classes. > > > > >>> > > > > >>> There is a file called JndiDefaultsGui which seems a bit odd. > > > > >>> > > > > >>> > > > > >>> Not sure if these matter. > > > > >>> > > > > >>> > > > > >>> --------------------------------------------------------------------- > > > > >>> To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > >>> For additional commands, e-mail: [EMAIL PROTECTED] > > > > >>> > > > > >>> > > > > >>> > > > > >> > > > > >> --------------------------------------------------------------------- > > > > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > >> For additional commands, e-mail: [EMAIL PROTECTED] > > > > >> > > > > >> > > > > >> > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
