You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jmeter.apache.org by Krzysieq <kr...@gazeta.pl> on 2008/04/01 09:47:55 UTC
Re: Property files question
Ok, I'll try to show some of the bigger picture. We have an internal tool
for management of property files. We use those files not only for tests, but
also for building our software. They are generated per-environment. Each
contains over 50 props, not all of which are relevant to the tests, but all
of them are different, or at least can be different, in each file. We also
have test campaigns that CruiseControl runs against different envirionments
- acceptance, integration and so on. Here our property files work fine
because there's no gui, and a set of tests is run only once.
To "emulate" that behavior in the gui mode, our jmeter files contain one
ugly walkaround. Each of them has a "user defined variables" element per
environment (gives us 4 sets of the same properties per jmx), which use the
syntax ${__P(property,default)} to use whatever comes from a file, or the
default value for the particular environment in case no prop file is
supplied (as in gui mode usually). Enable the one You want, disable the
rest, and You're testing the environment You want. This works, but is ugly
as hell and we'd like to drop it in favor of a cleaner solution. It's
possible to have 4 shortcuts on the desktop each starting jmeter with a
different property file. This is a solution, although not the prettiest
either, because then our tests start to depend on the configuration of the
machine, from which they are run.
So my question is - how can we do it otherwise? To answer Your question -
yes, we want to change all JMeter properties that come from a property file.
These are not all properties that are in the test however. We have some that
are env-independent. In general - things like application paths, ports etc
come from prop files, whereas test data is common to all platforms.
The best would be to switch between the files without having to switch off
the app. Or - referring to what You also wrote down there - would it be
possible to have just one set of configs, and use a script to overwrite the
values of properties defined in there using a property file, and based on
the value of a parameter that tells the environment to be tested?
Thanks for all help up to this point :)
Cheers,
Chris
2008/3/31, sebb <se...@gmail.com>:
>
> On 31/03/2008, Krzysieq <kr...@gazeta.pl> wrote:
> > 2008/3/31, sebb <se...@gmail.com>:
> >
> > >
> > > In 31/03/2008, Krzysieq <kr...@gazeta.pl> wrote:
> > > > Hi folks,
> > > >
> > > > A quick question which I didn't find an answer to in the docs: in
> our
> > > > projects we use many different testing platforms. Obvious choice
> here
> > > is to
> > > > use property files to store their configuration for our test
> purposes.
> > > And
> > > > this works perfectly with automatic test campaigns on
> cruisecontrol.
> > > > However, people often need to run the tests using the gui from
> their
> > > own
> > > > machines, against different platforms. How can we go about this
> fact
> > > > otherwise than by starting jmeter on command line with different
> -p
> > >
> > >
> > > Or you can use the -q argument or user.properties ..
> > >
> > >
> > > > argument? This is annoying cause You have to restart the app all
> the
> > > time if
> > > > You need to run the tests on different machines.
> > >
> > >
> > > ... but of course those won't help after JMeter has been loaded
> > >
> > >
> > > > Also, another ugly as hell
> > > > solution is to store all configuration in several user variable
> config
> > > > elements inside the tests. This is what we're unfortunately doing
> right
> > > now,
> > > > but we want to drop this in favor of some cleaner solution. Any
> help
> > > will be
> > > > greatly appreciated.
> > >
> > >
> > > So what you want is a way of updating a set of properties from the
> GUI?
> >
> >
> >
> > Not really update - I need to switch between sets of property files.
> When
>
>
> Do you really want to change *all* the JMeter properties?
> Probably there are some common ones.
>
> The others need to be defined for the first test, and then changed
> (updated) for subsequent tests.
>
> So long as all the different property files define values for the same
> set of properties, this is easy.
>
>
> > You load one on startup using -p, You're stuck with it until You switch
> off
> > and back on again.
>
>
> Not quite, you can change or add properties using the setProperty
> function.
>
>
> > This is a pain. On the other hand, I need to avoid using
> > many config sets insisde one tests, because they're difficult to
> maintain,
> > especially as the number of tests grows.
> >
> >
> >
> > The Property Display element:
> > >
> > >
> > >
> http://jakarta.apache.org/jmeter/usermanual/component_reference.html#Property_Display
> > >
> > > allows one to change individual properties, but I assume there are
> too
> > > many for that to be feasible.
> > >
> > > I suppose the test element could be extended to allow a property file
> > > to be loaded.
> > >
> > > Alternatively, you could write a BeanShell function to load the
> JMeter
> > > properties from a file name passed to it. This can be invoked via a
> > > dummy variable definition on the Test Plan.
> >
> >
> >
> > But would this override the set of properties defined on startup? Or if
> I
>
>
> Yes, if that's you code it to do ... the suggestion is to mimic the -q
> flag, which allows one to provide additional / replacement properties.
>
> Deletion of existing properties would need special handling, because
> JMeter sets up some of its own during startup. If you clear out the
> JMeter properties before loading the new ones, you may lose some vital
> properties.
>
> That's why I referred to updating the properties.
>
>
> > run the tests with one of these, can I use another file on another run
> of
> > tests? I haven't used beanshell or jexl, but maybe it's high time I do.
> >
> >
> >
> > The BeanShellFunction.bshrc sample init file has function definitions
> > > for gettting and setting properties, but it would probably be easier
> > > to load the property file into a temp. object and then add that to
> the
> > > existing properties. For example code, have a look at how the -q
> > > option is handled in JMeter.java - search for
> > > case PROPFILE2_OPT:
> > >
> > > You could probably use Jexl for this instead if you don't want to use
> > > BeanShell.
> > >
> > > > Best regards,
> > > > Chris
> > > >
> > >
> >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>
Re: Property files question
Posted by sebb <se...@gmail.com>.
On 01/04/2008, Krzysieq <kr...@gazeta.pl> wrote:
> Ok, I'll try to show some of the bigger picture. We have an internal tool
> for management of property files. We use those files not only for tests, but
> also for building our software. They are generated per-environment. Each
> contains over 50 props, not all of which are relevant to the tests, but all
> of them are different, or at least can be different, in each file. We also
> have test campaigns that CruiseControl runs against different envirionments
> - acceptance, integration and so on. Here our property files work fine
> because there's no gui, and a set of tests is run only once.
Do all the files define the same set of property names?
If so, then what I suggested will work.
If not, then you would need to extend the fix to first delete the
properties defined in the first file, before applying the properties
in the new file. This would mean keeping a copy of the currently
loaded properties separately from the JMeter properties.
> To "emulate" that behavior in the gui mode, our jmeter files contain one
> ugly walkaround. Each of them has a "user defined variables" element per
> environment (gives us 4 sets of the same properties per jmx), which use the
> syntax ${__P(property,default)} to use whatever comes from a file, or the
> default value for the particular environment in case no prop file is
> supplied (as in gui mode usually). Enable the one You want, disable the
> rest, and You're testing the environment You want. This works, but is ugly
> as hell and we'd like to drop it in favor of a cleaner solution. It's
> possible to have 4 shortcuts on the desktop each starting jmeter with a
> different property file. This is a solution, although not the prettiest
> either, because then our tests start to depend on the configuration of the
> machine, from which they are run.
I don't follow why the machine config should affect only the shortcut
method - what differences are you referring to?
> So my question is - how can we do it otherwise? To answer Your question -
> yes, we want to change all JMeter properties that come from a property file.
> These are not all properties that are in the test however. We have some that
> are env-independent. In general - things like application paths, ports etc
> come from prop files, whereas test data is common to all platforms.
Exactly. So put the common properties in jmeter.properties (or
user.properties) or even a secondary properties file loaded via -q,
and then load the test properties as I suggested previously.
> The best would be to switch between the files without having to switch off
> the app. Or - referring to what You also wrote down there - would it be
> possible to have just one set of configs, and use a script to overwrite the
> values of properties defined in there using a property file, and based on
> the value of a parameter that tells the environment to be tested?
That's exactly what I wrote previously. The parameter that defines the
environment is the name of the file containing the environment
properties.
> Thanks for all help up to this point :)
> Cheers,
> Chris
>
>
> 2008/3/31, sebb <se...@gmail.com>:
> >
> > On 31/03/2008, Krzysieq <kr...@gazeta.pl> wrote:
> > > 2008/3/31, sebb <se...@gmail.com>:
> > >
> > > >
> > > > In 31/03/2008, Krzysieq <kr...@gazeta.pl> wrote:
> > > > > Hi folks,
> > > > >
> > > > > A quick question which I didn't find an answer to in the docs: in
> > our
> > > > > projects we use many different testing platforms. Obvious choice
> > here
> > > > is to
> > > > > use property files to store their configuration for our test
> > purposes.
> > > > And
> > > > > this works perfectly with automatic test campaigns on
> > cruisecontrol.
> > > > > However, people often need to run the tests using the gui from
> > their
> > > > own
> > > > > machines, against different platforms. How can we go about this
> > fact
> > > > > otherwise than by starting jmeter on command line with different
> > -p
> > > >
> > > >
> > > > Or you can use the -q argument or user.properties ..
> > > >
> > > >
> > > > > argument? This is annoying cause You have to restart the app all
> > the
> > > > time if
> > > > > You need to run the tests on different machines.
> > > >
> > > >
> > > > ... but of course those won't help after JMeter has been loaded
> > > >
> > > >
> > > > > Also, another ugly as hell
> > > > > solution is to store all configuration in several user variable
> > config
> > > > > elements inside the tests. This is what we're unfortunately doing
> > right
> > > > now,
> > > > > but we want to drop this in favor of some cleaner solution. Any
> > help
> > > > will be
> > > > > greatly appreciated.
> > > >
> > > >
> > > > So what you want is a way of updating a set of properties from the
> > GUI?
> > >
> > >
> > >
> > > Not really update - I need to switch between sets of property files.
> > When
> >
> >
> > Do you really want to change *all* the JMeter properties?
> > Probably there are some common ones.
> >
> > The others need to be defined for the first test, and then changed
> > (updated) for subsequent tests.
> >
> > So long as all the different property files define values for the same
> > set of properties, this is easy.
> >
> >
> > > You load one on startup using -p, You're stuck with it until You switch
> > off
> > > and back on again.
> >
> >
> > Not quite, you can change or add properties using the setProperty
> > function.
> >
> >
> > > This is a pain. On the other hand, I need to avoid using
> > > many config sets insisde one tests, because they're difficult to
> > maintain,
> > > especially as the number of tests grows.
> > >
> > >
> > >
> > > The Property Display element:
> > > >
> > > >
> > > >
> > http://jakarta.apache.org/jmeter/usermanual/component_reference.html#Property_Display
> > > >
> > > > allows one to change individual properties, but I assume there are
> > too
> > > > many for that to be feasible.
> > > >
> > > > I suppose the test element could be extended to allow a property file
> > > > to be loaded.
> > > >
> > > > Alternatively, you could write a BeanShell function to load the
> > JMeter
> > > > properties from a file name passed to it. This can be invoked via a
> > > > dummy variable definition on the Test Plan.
> > >
> > >
> > >
> > > But would this override the set of properties defined on startup? Or if
> > I
> >
> >
> > Yes, if that's you code it to do ... the suggestion is to mimic the -q
> > flag, which allows one to provide additional / replacement properties.
> >
> > Deletion of existing properties would need special handling, because
> > JMeter sets up some of its own during startup. If you clear out the
> > JMeter properties before loading the new ones, you may lose some vital
> > properties.
> >
> > That's why I referred to updating the properties.
> >
> >
> > > run the tests with one of these, can I use another file on another run
> > of
> > > tests? I haven't used beanshell or jexl, but maybe it's high time I do.
> > >
> > >
> > >
> > > The BeanShellFunction.bshrc sample init file has function definitions
> > > > for gettting and setting properties, but it would probably be easier
> > > > to load the property file into a temp. object and then add that to
> > the
> > > > existing properties. For example code, have a look at how the -q
> > > > option is handled in JMeter.java - search for
> > > > case PROPFILE2_OPT:
> > > >
> > > > You could probably use Jexl for this instead if you don't want to use
> > > > BeanShell.
> > > >
> > > > > Best regards,
> > > > > Chris
> > > > >
> > > >
> > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
> > > >
> > > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org