CODEWITHSUNDEEP
grails
Anonymous Human
Anonymous Human

Reputation: 1948

Grails: CLI interaction while application is running

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.

Upvotes: 0

Views: 161

Answers (2)

chubbsondubs
chubbsondubs

Reputation: 38885

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.

Upvotes: 1

Joshua Moore
Joshua Moore

Reputation: 24776

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.

Upvotes: 1

Related Questions