Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

ScriptRunner does not recompile a composite class when any of its delegate classes is updated

Jedrzej Wolski August 28, 2018

I use JIRA server 7.2.12, ScriptRunner 5.4.12. and SVN for maintaining Groovy scripts.

I have implemented in Groovy, a generic listener class to be extended later by multiple concrete classes to be run as custom scripted listeners. This generic listener class uses some utility class as follows:

 

abstract class AbstractMyClassListener extends AbstractIssueEventListener {

// incorporate utility class
  @Delegate protected MyUtilsClass myUtilsClass = new MyUtilsClass()

// (...) here goes the code of generic listener

}

The static checker says the abstract class and utility class are correct.

When I set up all the needed custom listeners, the static checker says all the concrete classes for custom scripted listeners are correct as well.

Problem:

All the custom scripted listeners implemented as concrete classes extending AbstractMyClassListener, work perfectly fine until MyUtilsClass is updated in the server file tree.

After such update, for each custom listener, I'm starting to receive errors:

groovy.lang.MissingMethodException: No signature of method: aaa.bbb.ccc.listener.MyConcreteListenerClass.myUtilsClassMethod() is applicable for argument types: () values: []

The problem persists and is not gone away even if I clear the cache (both JIRA cache and Groovy class cache) using built-in scripts provided with ScriptRunner plug-in.

Moreover, the static checker still gives the green light to the code.

Diagnosis:

Seems like the ScriptRunner is unable to detect itself that some basic class has been updated and there is a need to recompile all the classes using that basic class.

Even clearing the cache (both JIRA cache and Groovy class cache) does not trigger the recompilation.

Also seems like the static checker is unable to detect the change. Could it be that the static checker and the compiler used by ScriptRunner are two different tools?

Workaround:

When any utility class has been updated:

1. First, do fake, manual edit on the AbstractMyClassListener class.

2. Second, do fake, manual edit on each concrete class extending AbstractMyClassListener class.

3. All the edits must be made in the sequence reflecting strictly existing class hierarchy, means starting from the lowest classes up till concrete classes.

4. Go to the custom listener entries, click edit, try to pick up code files once again, see that static checker is working and finally reports the code is correct.

5. See in the JIRA log or in the custom listener logs page, that all groovy.lang.MissingMethodException errors are gone. 

Expected resolution:

The ScriptRunner should block any code execution until the code is fully re/compiled.

Static checker should not give a green light to the code until the code is fully re/compiled.

Clearing the JIRA cache and Groovy class cache through ScriptRunner built-in, should be fixed to do its intended job.

Clearing the cache built-in should be more verbose about actions it takes and block until 1)  the cache is cleared 2) classes are fully recompiled.

1 answer

Suggest an answer

Log in or Sign up to answer
1 vote
Slava Dobromyslov
Contributor
January 8, 2023

Also, you may try to use a built-in ScriptRunner script "Clear Groovy classloader or Jira internal caches".

TAGS
AUG Leaders

Atlassian Community Events