Re: Strangenesses in JMS protocol files
I've removed some unused classes. Also, the JMSConfigGui class has been fixed to work as a Config element. There seem to be rather a lot of fields on the form - are they all likely to be needed as configuration items? Perhaps some fields are only really needed for the sampler? S. On 4/27/05, sebb <[EMAIL PROTECTED]> wrote: > OK thanks, that's what I was beginning to realise... > > I'll check the classes and delete them if they don't add anything useful. > > S. > On 4/27/05, Michael Stover <[EMAIL PROTECTED]> wrote: > > 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 > > > > > > >> > > > > > > >> > > > > > > >>
Re: Strangenesses in JMS protocol files
OK thanks, that's what I was beginning to realise... I'll check the classes and delete them if they don't add anything useful. S. On 4/27/05, Michael Stover <[EMAIL PROTECTED]> wrote: > 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. > > > > > >>> > > > >
Re: Strangenesses in JMS protocol files
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] > > > > >> > >
Re: Strangenesses in JMS protocol files
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] > > ---
Re: Strangenesses in JMS protocol files
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]
Re: Strangenesses in JMS protocol files
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]
Re: Strangenesses in JMS protocol files
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. 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? 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]
Re: Strangenesses in JMS protocol files
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]
Re: Strangenesses in JMS protocol files
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]
