I usually set properties within the run in Jmeter. How can remove all these properties after the run without knowing their names?
I usually use props.remove() to remove only one specific property, but how can remove all?
Properties lifetime is limited by the JVM lifetime so it's enough to restart JMeter to remove any custom properties.
Use props.clear() function in any of the JSR223 Test Elements (the syntax assumes Groovy language)
Demo:
However if you want to keep original JMeter properties for whatever reason:
You can store them into and interim object (or to the file) somewhere in setUp Thread Group and restore it in the tearDown Thread Group
Related
Thread Group A: use challenge-response to generate user token. Save as JMeter property.
Thread Group B: Run several samplers, one of which uses that token in a header.
Of course, the easy thing to do is run A, then B.
But let's say I want to use a "modular" approach and run only B.
I thought I recall seeing either in SO or Blazemeter that the JMeter object model allows one in a JSR223 Sampler to reference other samplers, even in another thread.
Other ideas also appreciated.
JSR223 Sampler cannot "call" another sampler neither from current nor in another Thread Group.
The only way of implementing this I can think of is storing the "common" logic as a Test Fragment and calling it where required using Module Controller
Currently I read properties file by defining a global element like;
> <configuration-properties doc:name="Local Configuration Properties"
> doc:id="899a4f41-f036-4262-8cf2-3b0062dbd740"
> file="config\local_app.properties" />
But this is not enough for me
when try to deal different clients dynamically.
Usecase
I need to pick right configuration file when request comes in. That is, for different clients I have different properties file.( their credentials and all different). When request is received from listener, i'll check with clientid header and based on that value, i'll pick right configuration file. My properties files are added to different location.(Doing deployment through openshift.) Not within mule app. So, we don't need to redeploy the application each time, when our application supports new client.
So, in this case, how to define ? and how to pick right properties file?
eg:
clientid =google, i have properties file defined for google-app.properties.
clientid=yahoo, i have properties file defined for yahoo-app.properties.
clientid=? I'll add properties file ?-app.properties later
Properties files are read deployment time. That means that if you change the values, you to redeploy the application to read the new ones. System properties need a restart of the Mule Runtime instance to be set. And Runtime Manager properties need a restart of the application. In any case the application will restart. Properties can not be used as you want.
There is no way to use configuration properties dynamically like that. What you could do is to create a module using Mule SDK that read properties files and returns the resulting set of properties, so you can assign the result to a variable, and use the values as variables. You will need to find a way to update the values. Maybe set a flow with a scheduler to read the values with a fixed frequency.
I have a clustered environment that has two WebSphere Application Servers.
In side the Process definition > Java Virtual Machine > Custom properties section for my servers I store several properties.
Is there any way to share values in this section between two app servers?
I don't think you can share JVM custom properties among multiple servers. However, you can create WebSphere variables (Environment > WebSphere Variables). When you create a variable there, you can choose a scope that will allow the variable to apply to multiple servers. That variable won't work the same as a JVM custom property, so what happens next depends on how the variable is used. If you need to access the variable inside the application, see this link:
http://www.slightlytallerthanaverageman.com/2007/04/02/access-websphere-variables-in-j2ee-applications/
If you need it to act like a JVM custom property, WAS might do variable expansion on JVM custom proerties. Say you defined a WebSphere variable named "WAS_VAR_X" and needed that variable to be set as a JVM property named "jvmPropertyX." You might be able to define the JVM custom property with:
Name: jvmPropertyX
Value: ${WAS_VAR_X}
I haven't tried this myself, so if you try it and it doesn't work, reply so I can edit the answer.
Maybe you can use database/cache(redis, etc) storing the share value.
When the app startup, load properties from database/cache(redis, etc).
Also you can change the properties and the other server can load new shared values.
GUI mode is interesting.
At this moment I create one component (i.e. assertion) and then copy and paste it on every place where it's needed. But if I change assertion in some place I must manually change all same assertions in all other places where its used.
Reusability in Jmeter can be done in 4 ways:
include controller when you want to reuse a subset of test (login, logout)
module controller to reuse controller in existing plan
user defined variables that you can reuse everwhere
xxx defaults for some samplers ( Ftp, Http...)
But in your particular case you can do it as below.
Define your expression as a var in User Defined Variable then use it in your assertions:
http://jmeter.apache.org/usermanual/component_reference.html#User_Defined_Variables
For sampler use Http Request Defaults to factor what is common between them.
http://jmeter.apache.org/usermanual/component_reference.html#HTTP_Request_Defaults
Note that to find elements with same regexp expression yoy can use search feature which highlights results of search.
IMHO The cleanest way to reuse components is to use ModuleController with jMeter Plugins' ParametrizedController.
The ParametrizedController link above will explain you how it's done.
I need to update the JSF2.0 (Primefaces) tooltips dynamically without server restart.
Meaning need to find a way where tooltips (atm from properties file) of the a running application can be changed without requiring a server restart.
We are running websphere and deploying a non exploded EAR (can probably convince to deploy exploded war)
Any Ideas or tips please. Thanks you
The value attribute of the p:toolTip component must be an EL expression or a literal text. Usually, one would reference a resource bundle declared using the var attribute of the f:loadBundle tag, in the EL expression for the tooltip.
The underlying resource bundle declared using the basename attribute could be backed by a property file itself (in which case you need to place the property file in the appropriate directory on the classpath), or for that matter it could be a custom ResourceBundle implementation that could read from a properties file (located outside the container), or a database or any store for that matter.
You could therefore change your existing EL expression from the existing one defined as:
<f:loadBundle var="msg" basename="propfile_location" />
to
<f:loadBundle var="msg" basename="fully qualified class name of the ResourceBundle class" />
In simpler words, you will need to roll your own ResourceBundle class(es) to support the various locales. Needless to state, but you will need to override the ResourceBundle.getObject(java.lang.String) method, as it is invoked by the ResourceBundleELResolver implementation when evaluating the EL expressions referencing ResourceBundles.
Additionally, you will need to ensure that the ResourceBundle.getObject(java.lang.String) implementation of your ResourceBundle will always re-fetch and return the value corresponding to the provided key. Failure to ensure this would mean that the initial value fetched by the resource bundle may be returned on subsequent invocations, especially if you are caching the initial value. You are likely to encounter this behavior even if you deploy an exploded WAR file where you can modify the property file contents without a redeployment of the application, and that is why it is important to use a custom ResourceBundle implementation that does not cache values.