I’ve found problem with run-script and many-to-many relations (lazy initialisation exception). And there is fix - change shell execution routine to following:

appCtx.getBeansOfType(PersistenceContextInterceptor).each { k,v ->
v.init()
}
def shell = new GroovyShell(classLoader, new Binding(ctx: appCtx, grailsApplication: grailsApp))
shell.evaluate(script.text)
appCtx.getBeansOfType(PersistenceContextInterceptor).each { k,v ->
v.flush()
v.destroy()
}
And add
import org.codehaus.groovy.grails.support.*
to resolve PersistenceContextInterceptor.

Thanks, Michael.

Thanks for the follow up message, that makes sense. I used to do a fair amount of programming on windows, but I always used the cygwin shell, which I think would treat this in the same way that it does on my Mac.

I now feel it necessary to mention that I’m running Windows XP… and unfortunately this plays a role in what’s occurring. After digging through the Init.groovy code, tracing back to where the system property grails.cli.args is set and doing some more playing in that, I decided to go even further back — to the batch file that actually launches grails on Windows machines (startGrails.bat). Even that batch file was seeing the equals sign as a space. I then created a dummy batch file:

echo %1 %2 %3

And ran it:

test.bat –id=15 b c

I’d expect the output to be the same parameters I passed in: “–id=15 b c”. But Windows has a better idea:

–id 15 b

To wrap things up, everything works fine if I wrap my equals-containing parameter in double-quotes, like so:

grails test-run argumentOne argumentTwo “–id=15″ argumentFour

Finally I get the desired result:

arguments are:
argumentOne
argumentTwo
–id=15
argumentFour
argsMap = [”params”:[”argumentOne”, “argumentTwo”, “argumentFour”], “id”:”15″]

I’m glad you found it useful!

Regarding the issue you’re asking about, I’m actually not seeing the same behavior that you’re seeing with the “=” getting stripped out. I get the normal java behavior of splitting on a space (which leaves the “-id=15″ intact. In the original script above, I actually have a “parseArguments” Gant target that takes advantage of the = being there. This method is part of grails 1.0.3, so you should have it available if you call “parseArguments()” in your script.

Here’s a slightly modified version of your script that demonstrates it:

grailsHome = Ant.project.properties."environment.GRAILS_HOME"
 
includeTargets << new File ( "${grailsHome}/scripts/Init.groovy" )
target('default': "The description of the script goes here!") {
	parseArguments() // populates the argsMap variable
	println "arguments are:\n $args"
	println "argsMap = $argsMap"
}

when I run this command (slightly modified to have 2 dashes in front of the “id” for posix compliance):

grails test-run argumentOne argumentTwo --id=15 argumentFour

Here is the output:

Welcome to Grails 1.0.3 - http://grails.org/
Licensed under Apache Standard License 2.0
Grails home is set to: /usr/local/grails		
 
Base Directory: /Users/ted/Documents/workspace/testargs
Note: No plugin scripts found
Running script /Users/ted/Documents/workspace/testargs/scripts/TestRun.groovy
Environment set to development
Done parsing arguments: ["params":["argumentOne", "argumentTwo", "argumentFour"], "id":"15"] ...
arguments are:
 argumentOne
argumentTwo
--id=15
argumentFour
argsMap = ["params":["argumentOne", "argumentTwo", "argumentFour"], "id":"15"]

I’m currently running the same versions of grails/groovy that you are:

% groovy -v
Groovy Version: 1.5.6 JVM: 1.5.0_13-119
% grails version
Welcome to Grails 1.0.3 - http://grails.org/
...

Do you have the release version of 1.0.3 running? I’d also try just creating a clean app (”grails create-app testargs”) and pasting in the test script to see if you get the same behavior.

I’ve found this extremely helpful. I’m very surprised that something like this isn’t already part of the grails core. I wonder if anyone else has run into some issues dealing with command line arguments: specifically, the removal of equals signs (=) from within parameters.

Here’s my test script. Versions are:
– Welcome to Grails 1.0.3 - http://grails.org/
– Groovy Version: 1.5.6 JVM: 1.6.0_02-b06

import org.codehaus.groovy.grails.commons.GrailsClassUtils as GCU
grailsHome = Ant.project.properties.”environment.GRAILS_HOME”
includeTargets << new File ( “${grailsHome}/scripts/Init.groovy” )
target(’default’: “The description of the script goes here!”) {
println “arguments are: \n” + args + “\n”
}

When I run “grails test-run argumentOne argumentTwo –id=15 argumentFour”, I get:

arguments are:
argumentOne
argumentTwo
–id
15
argumentFour

It seems that some piece of the initialization, in turning the args variable from an array to a newline-delimited string, is treating that equals sign in “–id=15″ as a separator rather than part of the argument.

Has anyone seen a way to either a) get it to stop doing that or b) get at the original command line parameters?

Thanks!

Perfect, thanks a million!

I agree with the comment it should be built into grails!

I am fairly new to Grails, and for some strange reason I expected to be able to do this “out of the box” with scripts. I see I have a long way to go to understand the Grails infrastructure.

I think “run-script” needs to become part of the standard infrastructure!

Thanks again,

John Hurst
Wellington, New Zealand

@Mike: Yep, using it in a batch program is exactly what drove me to make this in the first place :)

@Armin: Do you have a script that you can share that’s exhibiting a problem? My understanding of the bug that you linked to shouldn’t affect the way that this run-script gant task works.

I’ve run into the issue that you speak of when I try to save an object, but then forget to check .hasErrors() on it after the save to see if it was successful.

The linked issue seems to be due to the normal grails shell executing one statement at a time and associating a different hibernate context with each. Since context info isn’t shared across multiple statements in the grails shell, they fail. The way run-script is compiling the grails script with a single “evaluate”, I’d think it wouldn’t suffer from this. The entire script should be run with the same hibernate session in scope.

I recreated the Customer->Sites example given in the post and was able to run the example script without hitting an issue.

I created and ran 2 test scripts with this command:

grails run-script testScript.groovy testScript2.groovy

And got this output:

testScript all done! Customer : 1, Cust sites: [Site : 1] and Site : 1
In script 2: [Customer : 1]

script1.groovy:
def s = new Site(name: “foo”)
s.save()
if (s.hasErrors()) {
println “Site Errors: ${s.errors}”
}
def cust = new Customer(name: “bar”, sites: [s])
cust.save()
if (cust.hasErrors()) {
println “Cust errors: ${cust.errors}”
}
println “testScript all done! $cust, Cust sites: ${cust.sites} and $s”

script2.groovy:
println “In script 2: ${Customer.list()}”

Again, if you have an example that demonstrates the problem, I’d love to see it.

In my script, I got the error: “failed to lazily initialize a collection of role: …, no session or session was closed”, but this seems to be the same problem like in the Shell (in the Console it works): http://www.nabble.com/domain-relationships-in-shell—console-td15434264.html#a15435468

Armin