[3.1.4] Changing/reloading watched resources not triggering plugin's onChange.

[budjb]

I've got a plugin that defines 2 custom artefacts, and the plugin watches those files for changes and contains an onChange method. I've noticed that while running locally (gradle bootRun and grails run-app), changing and reloading those artefacts does not trigger the onChange method in the plugin. I have confirmed that the onChange method signature is correct.

I've poured through the source looking for clues, and found a couple of things in coordination with the IntelliJ debugger. The GrailsApp class contains a loop looking for changed and new files. This loop does execute when a local file is changed. The only time plugins are notified to fire the onChange method, however, is when the file is new ^source. Thus, files that have only been changed do not trigger a notification to run the onChange method when they have already existed.

I see other code in DefaultGrailsPlugin that does the actual work of calling a plugin's onChange method, but most of those methods are never actually referenced anywhere in the project.

It seems like the watcher loop in GrailsApp is the place to notify of changes, but I don't understand why there's a check that only triggers an onchange notification only for new files.

[budjb]

Further, it looks like the spring loaded component informs the plugin manager of class changes, but the plugin manager will only trigger an onchange for plugins whose name matches that of the artefact type. This leads me to believe that the built-in plugins for things like controllers and services work currently, but most others do not.

[jeffscottbrown]

Are you seeing this when the plugin is used in a multi project build with an app that depends on the plugin?

[budjb]

I haven't tried that scenario. I created a standalone application that depended on some plugins that were built and deployed to maven local. I did all my debugging and research through IntelliJ on that application and discovered that my plugins' onChange methods were not being called.

I can help debug further, but I'm not sure where exactly in the Grails codebase is the code that's responsible for notifying plugins of file changes for files they're watching. There's several places I've found that watch for changes for different scenarios. If you can give me a pointer to where in the codebase it should be triggering the watched files updates, I'll see what else I can find.

[MilesBehind]

Hi,

we have the same problem: we added two watched resources:

  def watchedResources = [
    "file:./grails-app/menu/MainMenu.groovy",
    "file:./grails-app/security/Security.groovy"
  ]

but the onChange-method of our plugin is never called:

  @Override
  void onChange (final Map<String, Object> event) {
    println "onChange => event = $event"
  }

the onChange-method is not called for changes in Security.groovy, regardless wether the file is located in the plugin itself or in the application that uses our plugin.

Frank

[graemerocher]

@budjb So the plugin defines new ArtefactHandler instances? If so you may need to override ArtefactHandler.getPluginName() to return the name of the plugin associated with the artefacts.

See for example https://github.com/grails/grails-core/blob/master/grails-core/src/main/groovy/org/grails/core/artefact/ControllerArtefactHandler.java#L47

Let me know if that works for you.

[budjb]

I will try this to verify the behavior.

I don't think this solves the watched resources issue though. The spring-loaded functionality, once it detects a class has changed, calls GrailsPluginManager.informOfClassChange(Class<?> aClass). This is the only place in the source that ArtefactHandler.getPluginName() is referenced from. The informOfClassChange method does not use the watchedResources properties at all, but rather simply triggers an onChange call iff it finds a plugin matching the name returned from the ArtefaceHandler for the artefact type. Also, that it detects a class change is important, since it doesn't look like the source attempts to get the class' actual file name, which a lot of plugins rely on for detecting file changes with watchedResources.

What this means is that only one plugin can be notified of changes of an artefact, and that watchedResources has no effect for groovy or java files. I need the ability to watch artefacts from two different plugins as they have different reasons for doing some kind of reloading.

[graemerocher]

@budjb yes I agree the current behaviour is not ideal, we would need a way to reverse calculate the groovy file for a particular class and would have to scan potentially many directories to achieve that. I have not yet thought of the best way to do that.

The suggestion to use ArtefactHandler.getPluginName() as a short term workaround as that will effectively return the plugin that should handle changes. In the meantime I have scheduled a proper fix for 3.1.6

[budjb]

Gotcha, that sounds great then!

[budjb]

Thanks Graeme! 👍