Grails: CLI interaction while application is running - grails

Question

Is there anything bad about interacting with Grails via command line while an application is running? For example, I had an application running on my local machine via the grails run-app target and then I opened another command prompt and created a domain class, I noticed that it created the domain class and the equivalent test class but in the other terminal where I had the application running I got a fair bit amount of red text like this:
| Error 2015-03-01 10:40:10,392 [Thread-10] ERROR plugins.AbstractGrailsPluginManager
- Plugin [domainClass:2.3.8] could not reload changes to file [C:\Users\user\Dropbo
x\MoeStuff\Projects\qotd\grails-app\domain\qotd\Quote.groovy]: Ambiguous method overl
oading for method grails.spring.BeanBuilder#registerBeans.
Cannot resolve which method to invoke for [null] due to overlapping prototypes betwee
n:
[interface org.codehaus.groovy.grails.commons.spring.RuntimeSpringConfigurati
on]
[interface org.springframework.beans.factory.support.BeanDefinitionRegistry]
Message: Ambiguous method overloading for method grails.spring.BeanBuilder#registerBe
ans.
Cannot resolve which method to invoke for [null] due to overlapping prototypes betwee
n:
[interface org.codehaus.groovy.grails.commons.spring.RuntimeSpringConfigurati
on]
[interface org.springframework.beans.factory.support.BeanDefinitionRegistry]
Line | Method
->> 3034 | chooseMostSpecificParams in groovy.lang.MetaClassImpl
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
| 2986 | chooseMethodInternal in ''
| 2929 | chooseMethod . . . . . . . . in ''
| 1204 | getMethodWithCachingInternal in ''
| 3163 | createPogoCallSite . . . . . in ''
| 1306 | createPogoCallSite in groovy.lang.ExpandoMetaClass
| 147 | createPogoSite . . . . . . . in org.codehaus.groovy.runtime.callsite.CallS
iteArray
| 161 | createCallSite in ''
| 45 | defaultCall . . . . . . . . in ''
| 108 | call in org.codehaus.groovy.runtime.callsite.Abstr
actCallSite
| 116 | call . . . . . . . . . . . . in ''
| 156 | doCall in org.codehaus.groovy.grails.plugins.DomainC
lassGrailsPlugin$_closure3
| -2 | invoke0 . . . . . . . . . . in sun.reflect.NativeMethodAccessorImpl
| 57 | invoke in ''
| 43 | invoke . . . . . . . . . . . in sun.reflect.DelegatingMethodAccessorImpl
| 606 | invoke in java.lang.reflect.Method
| 1254 | jlrMethodInvoke . . . . . . in org.springsource.loaded.ri.ReflectiveInter
ceptor
| 90 | invoke in org.codehaus.groovy.reflection.CachedMetho
d
| 233 | doMethodInvoke . . . . . . . in groovy.lang.MetaMethod
| 1086 | invokeMethod in groovy.lang.MetaClassImpl
| 1110 | invokeMethod . . . . . . . . in groovy.lang.ExpandoMetaClass
| 910 | invokeMethod in groovy.lang.MetaClassImpl
| 411 | call . . . . . . . . . . . . in groovy.lang.Closure
| 767 | invokeOnChangeListener in org.codehaus.groovy.grails.plugins.Default
GrailsPlugin
| 716 | notifyOfEvent . . . . . . . in ''
| 731 | notifyOfEvent in ''
| 409 | informOfClassChange . . . . in org.codehaus.groovy.grails.plugins.Abstrac
tGrailsPluginManager
| 367 | informOfFileChange in ''
| 243 | informPluginManager . . . . in org.codehaus.groovy.grails.compiler.Grails
ProjectWatcher
| 46 | access$400 in ''
| 169 | onNew . . . . . . . . . . . in org.codehaus.groovy.grails.compiler.Grails
ProjectWatcher$1
| 210 | cacheFilesForDirectory in org.codehaus.groovy.grails.compiler.Direct
oryWatcher
| 204 | cacheFilesForDirectory . . . in ''
| 187 | checkForNewFiles in ''
| 163 | run . . . . . . . . . . . . in ''
^ 178 | run in org.codehaus.groovy.grails.compiler.Grails
ProjectWatcher
Can anyone please talk a bit about what this error(s) means? And is it ok to be doing what I was doing in the first place or should I ALWAYS stop an application from running before issuing any commands to grails that have to do with artefact creation/modification or do CLI interaction with Grails? Thanks.

Answer 1

It's a best practice to stop your application when doing artifact creation. Modification you can usually get away with keeping the application running, so long as you aren't doing major modifications to the class hierarchy.
The reason for this is in development mode Grails watches for changes artifacts and attempts to reload those changes. In the case of creation it may hit just at the wrong time and confuse your application (what you are seeing in your question).
Reloading of changed/new resources (Domain classes in particular) isn't perfect, but it works most of the time. Save yourself the headache and stop your application during creation.

Answer 2

So grails is going to try compile and load changes to files. So what you are seeing here is grails tried to compile a file you modified or were in the process of modifying and it failed.
Now how well can grails load and compile changes is a somewhat hit or miss. It will load them, but sometimes it just doesn't work and the server needs to be rebooted. Also the amount of processor needed to watch files can be overloaded especially when you checkout new code while your server is running.
So does this harm anything? Well no it just may or may not work. Your server may not reflect changes or it may give you wrong responses than what the code says because it couldn't loaded that code. Changing domain objects could affect your database or persistence layer, but some changes may not be compatible with your DB so you'll have to stop it.