Domain objects not reloaded when changed.

Is the problem that the domain class isn't reloading or that the domain class is reloading but dynamic scaffolding isn't picking up the change? I haven't investigated but my sense is that this is probably not a class reloading problem per se, but a problem with the scaffolding mechanism not noticing that the class has been reloaded.

Just to clarify my earlier comment... Either way it is a bug and we should address it.

I suspect that the domain class is not reloading since when I did generate-all it also did not pick up the changes to the domain class (new fields not added to the views)

I think the domain class is being reloaded but something hinky is happening.

It looks like when a new property is added, the dynamic scaffolding (probably other parts of the system too) isn't recognizing the new property. If I add another property, the first property then starts to show up in the dynamic scaffolding. If I add a third property, the second one shows up. It appears that somehow the system is 1 version behind the whole time. At least that is what my cursory test suggests.

In any case, we will get it straightened out. Thanks for the input Scott.

I'm seeing the same behavior, second save require to see the change

This is a threading / concurrent issue. The reload event was being fired too late on some occasions, adding a wait condition seems to alleviate the problem

Tested with RC2. Still broken. Added field, tried a few reloads. Still does not appear. Adding a comment will make it appear. Adding another field shows the previous field added but not the last one.

After 2-3 reloads gets:
Error 500: Internal Server Error
URI
/jira/contact/list
Class
groovy.lang.MissingMethodException
Message
No signature of method: jira.Contact.list() is applicable for argument types: () values: [] Possible solutions: list(), list(java.util.Map), last(), last(java.lang.String), last(java.util.Map), first()
Around line 15 of grails-app/controllers/jira/ContactController.groovy
Around line 186 of PageFragmentCachingFilter.java
183: if(method == null) {
184: log.debug("No cacheable method found for {}:{} {}",
185: new Object[]

);
186: chain.doFilter(request, response);
187: return;
188: }
189: Collection<CacheOperation> cacheOperations = cacheOperationSource.getCacheOperations(
Around line 63 of AbstractFilter.java
60: try {
61: // NO_FILTER set for RequestDispatcher forwards to avoid double gzipping
62: if (filterNotDisabled(request))

65: else {
66: chain.doFilter(req, res);
Trace
Line | Method
->> 15 | list in ContactController.groovy

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

  186	doFilter in PageFragmentCachingFilter.java
  63	doFilter in AbstractFilter.java
  886	runTask in java.util.concurrent.ThreadPoolExecutor$Worker
  908	run . . in '' ^ 680	run in java.lang.Thread

Which WILL go away on subsequent refreshes but additional field does not appear.

trying to recreate this at the moment to investigate but just works for me. I see the page correctly reflect the new field added. I have removed the sleep logic from GrailsPluginManagerReloadPlugin just to try and force it to happen. What precise java versions are you on, anyone that is seeing the problem? (I'm on 1.7.0_04-b21).

Ok, might be getting somewhere, I switched back to java 6 and it happened to me (1.6.0_35-b10-428-11M3811).

Have problem on:
Mac 10.8.2
java version "1.6.0_37"
Java(TM) SE Runtime Environment (build 1.6.0_37-b06-434-11M3909)
Java HotSpot(TM) 64-Bit Server VM (build 20.12-b01-434, mixed mode)

Ok, the problem here is stale JVM state that isn't quite cleared up properly on reload. I will put the change into springloaded to tidy this state up but the very simplest fix for grails (given that it is already in RC phase) is to add a single line to clear the cache from the reload plugin. The fix is to modify GrailsPluginManagerReloadPlugin.reloadEvent(), remove the sleep and change it to:

public void reloadEvent(String typename, Class<?> aClass, String encodedTimestamp) {
        CachedIntrospectionResults.clearClassLoader(aClass.getClassLoader());
        ClassPropertyFetcher.clearClassPropertyFetcherCache();
        if (GrailsProjectWatcher.isActive()) {
            Introspector.flushFromCaches(aClass);
            GrailsProjectWatcher.firePendingClassChangeEvents(aClass);
        }
}

The call to Introspector is the important call. The reason it looks a bit timing related is that weak reference maps are being used - when they are cleared up is a bit 'random' and it looks like the inclusion of a delay waits enough time that the refs will naturally disappear via GC. Calling Introspector flush will more pro-actively clean them up. This mechanism changed in Java7, hence you don't see the problem there.

I have made this change and it looks promising. For all of the scenarios that I have tested, the reloading consistently misbehaves without this change and consistently behaves with this change.

Andy, thanks a lot for digging into this.

Can the issue be closed then?

As far as I can see, yes. I will go ahead and close it. If anything comes up in testing we can revisit.