Creating of vim swp files impacting reloading

Never mind, this only seems to happen in my application, not in a newly generated one. It is probably caused by some plugin and I'm investigating which one could be the cause...

Ok, found out what the problem really is. I have some fixed roles for my application. Suppose they are 'admin', 'editor' and 'client'. So, instead of looking at the database every time I need them, I've done some caching:

class Role {
String name

private static roleByName

static byName(name)

private static processCache() {
if (roleByName) return
roleByName = list().inject([:])

}
}

I'll get weird error messages in development mode if I do that. Using Shiro and another class just for testing, I got this, for instance:

ERROR errors.GrailsExceptionResolver - LazyInitializationException occurred when processing request: [GET] /reloading/main/index
failed to lazily initialize a collection of role: reloading.ShiroUser.permissions, no session or session was closed. Stacktrace follows:
Message: failed to lazily initialize a collection of role: reloading.ShiroUser.permissions, no session or session was closed
Line | Method
->> 77 | isPermitted in ShiroDbRealm$$ENK01yVc

• - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  237	isPermitted in org.apache.shiro.grails.RealmWrapper
  58	isPermitted . . . . in org.apache.shiro.grails.RealmAdapter
  222	isPermitted in org.apache.shiro.authz.ModularRealmAuthorizer
  113	isPermitted . . . . in org.apache.shiro.mgt.AuthorizingSecurityManager
  151	isPermitted in org.apache.shiro.subject.support.DelegatingSubject
  511	accessControlMethod in ShiroGrailsPlugin$$ENK01dhI
  245	doCall in ShiroGrailsPlugin$_closure3_closure24$$ENK01dhI
  13	doCall . . . . . . in ShiroSecurityFilters$_closure1_closure2_closure3$$ENK01kSe
  55	doFilter in org.apache.shiro.grails.SavedRequestFilter
  359	executeChain . . . in org.apache.shiro.web.servlet.AbstractShiroFilter
  275	call in org.apache.shiro.web.servlet.AbstractShiroFilter$1
  90	doCall . . . . . . in org.apache.shiro.subject.support.SubjectCallable
  83	call in ''
  344	execute . . . . . . in org.apache.shiro.subject.support.DelegatingSubject
  272	doFilterInternal in org.apache.shiro.web.servlet.AbstractShiroFilter
  81	doFilter . . . . . in org.apache.shiro.web.servlet.OncePerRequestFilter
  886	runTask in java.util.concurrent.ThreadPoolExecutor$Worker
  908	run . . . . . . . . in '' ^ 662	run in java.lang.Thread

In my real case, I moved the caching to a service, but still have problems. I changed my code for not caching in development mode to something like this:

class RoleService {
def allRoles, roleByName = [:]

def getAllRoles()

private processAllRoles() {
if (allRoles && Environment.current != Environment.DEVELOPMENT) return
//allRoles = ShiroRole.ROLE_NAMES.collect

allRoles = ShiroRole.ROLE_NAMES.collect{roleName -> ShiroRole.withCriteria

}
allRoles.each

}

def byName(name)

}

If I use the withCriteria to fill "allRoles" I get this message:

No signature of method: security.ShiroRole.withCriteria() is applicable for argument types: () values: [] Possible solutions: withCriteria(groovy.lang.Closure), withCriteria(java.util.Map, groovy.lang.Closure), createCriteria()

If I use the findByName approach, I'll get:

No signature of method: security.ShiroRole.methodMissing() is applicable for argument types: () values: []

If I restart the application, everything goes fine until I touch ShiroRole.groovy.

Humm... I have changed the service to not use caching, and still get the same errors if I touch ShiroRole:

class RoleService {
def getAllRoles() {
ShiroRole.ROLE_NAMES.collect

}

def byName(name)

}

Any ideas on what could be happening?

This is what I get from the backtrace while calling withCriteria:

2011-12-24 11:15:12,419 ["http-bio-8081"-exec-6] ERROR StackTrace - Full Stack Trace:
java.lang.NullPointerException
at grails.orm.HibernateCriteriaBuilder.invokeMethod(HibernateCriteriaBuilder.java:1515)
at org.grails.datastore.gorm.GormStaticApi.withCriteria(GormStaticApi.groovy:261)

Now, this is really interesting... After setting my vim settings to "set noswapfile" it seems those problems were gone... Why the hell Grails is monitoring my swap files? They are called something like ".AccountController.groovy.swp". Somehow, this seems to be the cause of maybe some race condition in the reloading algorithm.

Any ideas?

Use a different editor for the moment. Textmate doesn't create swp files.

Textmate doesn't run on Linux. But this is no problem, as I've just disabled the swap files for now in gVim. But I'd like to be able to re-enable them some day when this gets fixed.

This is reproducible with vim, and pretty frustrating. More importantly, it could be a more pervasive problem. Anyway, to reproduce with vim:

1. Unpack the attach bug report
2. Start up interactive mode
3. Execute run-app
4. exit
5. Execute run-app a second time
6. Open the application in a browser
7. Try http://localhost:8080/library/book/hello (not implemented yet)
8. Now edit BookController.groovy in vim and add

def hello() {
    render "Hello world!"
}

9. Save
10. Refresh the browser.

You should find that BookController has not been reloaded, although there are no error messages.

I have pushed a potential fix, but because i was unable to see Grails monitoring any SWP files whilst debugging nor was I able to reproduce an exceptions or errors I would like someone to verify.

Using Peter's steps I was unable to reproduce any reloading failures with MacVim and :set swapfile

I've made some changes on current Grails 2.0.1 with the swapfiles enabled and I didn't get any further issues with regards to reloading of classes, so I think this bug was really fixed. Thanks!

Unfortunately I can't upgrade to 2.0.1 yet because it broke both mongo and mongo-morphia plugins and I don't know any other plugin for Grails for writing to Mongo, so I'll have to implement my logging to mongo in Groovy by myself before I'm able to upgrade to 2.0.1...