I'm trying to use Beanshell in a java application to execute "addon" files supplied by a user. Since the "main" code of the addon is called in a repeating loop, some addons need to use global variables initialized outside the scope of this code in order to keep track of things that require more than one loop cycle. I'm trying to do this by setting up a beanshell interpreter as
interpreter.eval("float xPositions;");
while(condition) {
interpreter.eval("xpositions++;");
}
The problem is, by the time beanshell gets the second eval, it's forgotten that the variable exists. Is there a way to stop it doing this?
This is the way to go: interpreter.set("myVarName", myValue);
Btw: There is a bugfix version of beanshell, called beanshell2 at http://code.google.com/p/beanshell2 available.
Related
I'm using jdk.jshell.JShell to evaluate Java code programmatically and I'd like to add a local variable to the active evaluation context, so the value is useable in the shell.
I'm instantiating the JShell with a DirectExecutionControl, so it runs on the same JVM as the main code. I've spent quite a lot of time stepping through the source code of the JDK trying to see where I could plug myself, but it's quite opaque; simply getting an Object result out of eval(...) instead of a String required a number of hacks (Oracle, why?).
The answer here seems to suggest that this is not possible, without justification, but I'm too deep into this to accept that.
Ideas I have thought about:
- creating a class dynamically, with a field corresponding to the variable I want to add, and `import static`ing that class into the JShell (but I don't know how to dynamically add an import either)
- trying to find one of the internal auto-generated classes JShell is using to store the variables, and replacing them using arcane reflection magic
in the first thread, I received JSON (format - {"id":6054,"name":"Jmeter created chat","description":"jmeter created test"})
I want to use it in the second thread variable '6054'
I use BeanShell Assertion with code:
${__setProperty(("id":"(.+?)"), ${chat_id)};
but it, of course, doesn't work, please tell me the right way..
many thanks
It won't work because your __setProperty() function call doesn't make sense at all and it's syntactically incorrect
Since JMeter 3.1 you're supposed to use JSR223 Test Elements and Groovy language for scripting
So
Remove your Beanshell Assertion
Add JSR223 PostProcessor as a child of the request which returns the above response
Put the following code into "Script" area:
props.put('chat_id', new groovy.json.JsonSlurper().parse(prev.getResponseData()).id as String)
In 2nd Thread Group access the value using __P() function as:
${__P(chat_id,)}
Demo:
More information regarding what these prev and props guys mean can be found in the Top 8 JMeter Java Classes You Should Be Using with Groovy article
P.S. You may find Inter-Thread Communication Plugin easier to use
I have started working with a large code base, and a lot of the code has been set up with a strange format for functions. more or less every function has the following format
foo(){
trace_messages()
// this is what I don't get
try{
// all code goes here
} finally {
trace_messages()
}
}
I can't see any sense behind the insistence on wrapping more or less the entire work of function in a try. Is this some sort of 'best practice' that I never got told about?
EDIT:
perhaps I should have stated, but the two calls to trace_messages() are actually different sections of code, but more or less the same... if you follow my meaning
The intention of that code was to make sure that trace_messages() was guaranteed to executed in the beginning and before the end of foo().
finally is guaranteed to execute both in case everything runs fine, and if the code inside try fails miserably with some nasty uncaught runtime exception.
I agree that the format chosen to achieve this intention is not of the best, normally that is done with some sort of AOP, in Spring you would wrap foo() into Around advice.
Find the definition of trace_messages(), and you will see what the last guy was trying to do. If you are using an IDE like Eclipse, right-click on trace_messages() and there should be an option to jump directly to the definition.
I have a process in drools with a process variable that gets set. I would like to be able to dynamically change what ruleflowgroup gets called based on the variable.
I have tried setting the ruleflowgroup to #{ruleFlowGroupName} but the rules never activate.
I have a script task right before the ruleflow group that prints out the value of the variable and it is correct.
I have done this before with a reconfigurable subprocess where the process id is a process variable and the process dynamically gets replaced when the main process runs.
I was hoping to be able to do this with specifying the ruleflowgroup too.
any ideas?
What is the business objective of doing that? if you have two different set of rules that evaluate different data depending on what you are inserting inside the drools engine, there is no need to have two different rule flow groups. Only the relevant rules will be activated.
Cheers
It is indeed true that a dynamic ruleflowgroup name is currently not supported. I've created a JIRA for this so we can track this and you can keep updated on any progress.
https://issues.jboss.org/browse/JBPM-3552
It would indeed be useful to describe the situation where you think this might be useful, as there may be alternatives / workarounds already.
I am looking for a way to remove all uses of a particular class, including the class itself, at compile time. Basically a form of pre-processing, but I'd like to do it without having to surround all the instances with #ifdebug ... #endif.
Is there any ant-based tool out there that can do this? If not, can anyone point me in the right direction for how to write such a tool? (not a minor undertaking I know, but if its the only option...)
The situation is I have a helper class for debugging function calls. This is instantiated at the beginning of a function and a call is made at the end. This is a JavaME application so I'm nervous about the overhead this is adding to performance. I already have a release and debug build that have pre-processor directives using ProGuard, so I would like to exclude the use of this helper class from the release build. It doesn't appear this can be done with ProGuard.
"This is instantiated at the beginning of a function and a call is made at the end. "
If this is all over your code maybe you need to look at AOP.
or a state design pattern for the helper class, in test mode it does one thing but in prod it does another(like nothing)
Do you know that this debug code will make the JavaME app slow? You could also try creating a way to conditionally call these debug methods.
A few more ideas ... I've never written a JavaME app, but I assume there is way to run/test with running on the actual device. Given this way of running/testing, perhaps you can use Eclipse/Netbeans to debug your code and use proper breakpoints instead of programmatically tracing method calls. No harm to compiled code in this case. Also consider using AspectJ to trace method calls, this can be conditionally done after code is compiled since AspectJ alters bytecode directly (not sure how this plays with JavaME). Lastly, I've heard of people using the standard GNU C/C++ preprocessor on Java. I have no idea if it works, google will help you.
Not exactly what you want but...
You could separate your code to modules (core and debug, in your case), then make sure modules call each other via reflection: use an interface available in core, create a wrapper class in core that will hide object instantiation via reflection detail/
Then, on production, just omit the debug code and have the wrapper "do nothing" if the instantiation fail / when you set a specific flag.
This way your debug classes won't make it into production and you won't have to "statically link" to them so your core production code won't care.
Of course, this is only possible if your debug code has no side effects visible to core code, but it seems that's your case (from your problem description).
Is it possible to just create the class once, on application startup, instead of creating an instance for each method? Your debug class could then look like this:
public class Debug // maybe make this a *gasp* singleton?
{
public static void start(); // called at start of method
public static void end(); // called at end, probably should be in a finally block
public static void setDebugMode(boolean debugOn); // turn off for production mode
}
Set debug mode to "true" in testing but "false" in production. When debug mode is off, none of the methods do anything (except check the state of debug mode, of course).
You don't avoid the overhead of the function call, and you do need to check the state of that boolean, but you do get to avoid jumping through hoops trying to avoid load the class at all.
This will need more work if you have a multithreaded application, too.