This still looks like an issue to me with JMeter. Perhaps its related to both
JMeter and groovy having their own interpretation of ${var}. JMeter is
treating these as JMeter variables whereas groovy would treat them as GStrings.
Your right that saving the script to a file resolves the issue. Here's a much
simpler example...
def v1 = "ab\\c"
def v2 = "123 ${v1}"
This compiles fine in groovy and results in v2 having a value of "123 ab\c".
It also runs fine in JMeter when linked as a file. However, paste this into
the JSR223 script sampler and you'll get the same error as below. Remove the
"\\" part of the first string and then everything runs fine. Anyway, I'll just
reference my scripts from file, which is what I should be doing anyway.
________________________________
From: sebb <[email protected]>
To: JMeter Users List <[email protected]>; Glenn Caccia
<[email protected]>
Sent: Monday, December 23, 2013 2:58 AM
Subject: Re: Groovy GString incompatibility?
On 23 December 2013 02:58, Glenn Caccia <[email protected]> wrote:
>
>
> I have a JMeter test (2.10) that uses a JSR223 script sampler. The groovy
> script was working fine. I then learned about GStrings and decided to
> convert the script to use that. After making the change, the groovy script
> fails to compile in JMeter (compiles fine in groovy console).
>
> Here's an example, this will fail in JMeter:
>
> ==============================================================
>
> import groovy.sql.Sql
>
> def projectName = vars.get("projectName")
> def sql = Sql.newInstance("jdbc:sqlserver://SERVERNAME\\DBINSTANCE:PORT",
> "reporter", "reporter", "com.microsoft.sqlserver.jdbc.SQLServerDriver")
>
> //def row = sql.firstRow("select projectId from projects where projectName =
> '" + projectName + "'")
> def row = sql.firstRow("select projectId from projects where projectName =
> '${projectName}'")
> ==============================================================
>
> The JMeter log will report an unexpected character on the line for "def sql
> =" at character "\" in "SERVERNAME\\DBINSTANCE:PORT".
>
> If I uncomment the 2nd to last line and comment out the last line, then the
> script runs fine in JMeter. Am I missing something or is this a defect in
> JMeter?
It's not a defect in JMeter, which passes the GUI script content
direct to the scripting engine.
The only change JMeter makes is to replace any JMeter variable
references, such as in the last line.
This is a purely textual replacement; if JMeter matches ${varname} it
replaces the text with the value of the variable varname.
If there is no such variable, the text is not replaced.
One way to check for this is to put the script in a file instead of in
the GUI field.
That will be more efficient as it allows the script to be compiled;
JMeter does not scan files for variable references.
Having said that, the last line looks unnecessary - why use a JMeter
variable reference?
You already fetch the project name in the 2nd non-blank line, so the
previous line should work fine.
I suspect that the project name may contain some unsafe characters,
for example a single-quote.
> The error dump looks like:
>
> 2013/12/22 18:40:41 ERROR - jmeter.protocol.java.sampler.JSR223Sampler:
> Problem in JSR223 script javax.script.ScriptException:
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed:
> Script9.groovy: 5: unexpected char: '\' @ line 5, column 60.
>
>
> at
>org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:152)
> at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:216)
> at
>org.apache.jmeter.util.JSR223TestElement.processFileOrScript(JSR223TestElement.java:202)
> at
>org.apache.jmeter.protocol.java.sampler.JSR223Sampler.sample(JSR223Sampler.java:70)
> at
>org.apache.jmeter.threads.JMeterThread.process_sampler(JMeterThread.java:429)
> at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:257)
> at java.lang.Thread.run(Thread.java:662)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
