Script Runner: Import problem using Groovy utility class in inline Scripted Field

[David Turner]

Currently using latest: groovyrunner-3.0.7-SNAPSHOT plugin, but this was evident back to GRv2.x+Behaviours as well (hence attempting an upgrade). Running on JIRA 6.2.7 on Windows Server 2008 R2.

We have some Script Fields with inline groovy code in which we'd like to use/import a common utilty groovy class (WorkingTime.groovy) placed directly in JIRA_HOME/scripts (the script-root). The groovy class has no package.

Intermittently this works as expected, but often the groovy import fails to work, causing numerous problems whenever an issue including the field is accessed (loaded, indexed, search/filtered).

Example error below:

2014-11-18 11:20:58,336 ajp-apr-8009-exec-105 ERROR xxxxxx 680x126262x5 1ofxyh9 10.xxx.yyy.zzz /rest/api/latest/issue/XXX-4953 [onresolve.scriptrunner.customfield.GroovyCustomField] startup failed:
Script135186.groovy: 11: unable to resolve class WorkingTime
 @ line 11, column 1.
   import WorkingTime
   ^
1 error
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
Script135186.groovy: 11: unable to resolve class WorkingTime
 @ line 11, column 1.
   import WorkingTime
   ^
1 error

The WorkingTime groovy class (and other groovy scripts) do compile and work fine stand-alone when called with a main method through script-console, and others work as a listener or escalation class etc.

One curious observation is that the WorkingTime.groovy file often (again not always) appears to get locked for edits when the issue occurs.

Any hints on what might be going wrong with importing into inline script fields here?

Through reading I've found several references that scriptrunner should:

a) dynamically re-compile classes in script-root (but then why can't it find this class?). Using the built-in script to clear Java/Groovy class-loaders does not help.

b) log out any compilation problems, but I've not seen any such problem in the atlassian-jira.log for script-root classes.

I'm stuck for ideas for the moment and can't identify a root cause for the problem. I don't really want to inline the whole class into each field, or rip it all out into multiple external groovy files.

Thanks in advance Jamie

PS: Thanks so much for creating and maintaining this plugin. JIRA would be non-competitive if we did not have the ability to create these simple yet powerful customisations.

[JamieA · Accepted solution]

Hi David... I think this is this problem: https://jamieechlin.atlassian.net/browse/GRV-544

Well, I would think it is, but the intermittent part of this doesn't make much sense, it should either work or not. 

Can you confirm it really is the problem by putting one of the script field scripts into a file, and referencing that?

[Marco Hödtke]

This issue is from 2014 but I have a similar problem: For finding out how this works I have created a groovy class <scriptroot>/util/PresenceChecker.groovy and a groovy script in <scriptroot>/checkPresence.groovy. All the skript does is call a method of the class which returns "Yes I am here" as answer. This works fine if I do it from the script console. As Script file I set "checkPresence.groovy". When I do the same in the scipted field I get the error message "The file checkPresence.groovy cannot be found or cannot be read." If I paste the same code as  inline script I receive no error message but it is without any result. How does this work?

Jira Version 6.4.9

ScriptRunner Version 3.0.6

[David Turner]

Confirmed, that GRV-544 appears to be the problem.

Moving the inline ScriptField code to a file under script-root allows it to access the util class no problemo.

You've also convinced me that maybe this is a better solution anyway. Makes the scripts more portable between environments, I can use package heirarchies, and it is likely to perform better, so I'll proceed with this work-around. Thanks!

Re: the term intermittent. Sorry, probably not the most precise way of describing this bug. It was working, but broke after a server reboot (and actually haven't had it work successfully since). I wonder if, by fluke (when playing in Script Console etc) I managed to import the class in to a GroovyShell classloader some other way, and/or maybe I was running the groovyrunnerv2 and v3 jars together after plugin upgrade... in any case, my fault in that regard conflating this with other issues and for not strictly following your upgrade guidelines

Thanks, David.

[JamieA]

Hi David. Personally I think it is a better solution... there are various pros and a couple of cons, but the main one for me is ability to debug. Unfortunately it's not a sufficient solution in itself, well, not for everyone, because there are a few places like the Condition code in built-in workflow functions that have to be inline. Thanks for the rest of the info.