You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jmeter-dev@jakarta.apache.org by sebb <se...@gmail.com> on 2005/04/24 20:52:33 UTC
Strangenesses in JMS protocol files
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: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: Strangenesses in JMS protocol files
Posted by sebb <se...@gmail.com>.
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 <se...@gmail.com> 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 <ms...@apache.org> 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 <ms...@apache.org> 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, m.blankestijn@hccnet.nl <m....@hccnet.nl> 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 <wo...@gmail.com> 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 <se...@gmail.com> 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: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > >>> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > >>>
> > > > > > >>>
> > > > > > >>>
> > > > > > >>
> > > > > > >> ---------------------------------------------------------------------
> > > > > > >> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > >> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >
> > > > > > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: Strangenesses in JMS protocol files
Posted by sebb <se...@gmail.com>.
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 <ms...@apache.org> 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 <ms...@apache.org> 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, m.blankestijn@hccnet.nl <m....@hccnet.nl> 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 <wo...@gmail.com> 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 <se...@gmail.com> 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: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > >>> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>
> > > > > >> ---------------------------------------------------------------------
> > > > > >> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > >> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >
> > > > > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: Strangenesses in JMS protocol files
Posted by Michael Stover <ms...@apache.org>.
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 <ms...@apache.org> 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, m.blankestijn@hccnet.nl <m....@hccnet.nl> 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 <wo...@gmail.com> 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 <se...@gmail.com> 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: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > >>> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>
> > > > >> ---------------------------------------------------------------------
> > > > >> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > >> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > >>
> > > > >>
> > > > >>
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: Strangenesses in JMS protocol files
Posted by sebb <se...@gmail.com>.
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 <ms...@apache.org> 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, m.blankestijn@hccnet.nl <m....@hccnet.nl> 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 <wo...@gmail.com> 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 <se...@gmail.com> 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: jmeter-dev-unsubscribe@jakarta.apache.org
> > > >>> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > >>>
> > > >>>
> > > >>>
> > > >>
> > > >> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > >> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > >>
> > > >>
> > > >>
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > >
> > > >
> > > >
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: Strangenesses in JMS protocol files
Posted by Michael Stover <ms...@apache.org>.
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, m.blankestijn@hccnet.nl <m....@hccnet.nl> 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 <wo...@gmail.com> 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 <se...@gmail.com> 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: jmeter-dev-unsubscribe@jakarta.apache.org
> > >>> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > >>>
> > >>>
> > >>>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > >> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > >>
> > >>
> > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > >
> > >
> > >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: Strangenesses in JMS protocol files
Posted by sebb <se...@gmail.com>.
On 4/25/05, m.blankestijn@hccnet.nl <m....@hccnet.nl> 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 <wo...@gmail.com> 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 <se...@gmail.com> 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: jmeter-dev-unsubscribe@jakarta.apache.org
> >>> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> >>>
> >>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> >>
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> >
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: Strangenesses in JMS protocol files
Posted by m....@hccnet.nl.
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 <wo...@gmail.com> 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 <se...@gmail.com> 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: jmeter-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: Strangenesses in JMS protocol files
Posted by sebb <se...@gmail.com>.
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 <wo...@gmail.com> 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 <se...@gmail.com> 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: jmeter-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: Strangenesses in JMS protocol files
Posted by Peter Lin <wo...@gmail.com>.
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 <se...@gmail.com> 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: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org