JIRA 6.3.5
Scriptrunner 3.0.12
I am running into an intermittent issue where I have a custom canned script which subclasses another custom abstract canned script, e.g.:
package com.onresolve.scriptrunner.canned.jira.workflow.postfunctions import com.onresolve.scriptrunner.canned.jira.utils.AbstractTransitionIssue @ScriptListener class TransitionSubTasks extends AbstractTransitionIssue
Both classes are custom made and are located in these directories and packages:
com/onresolve/scriptrunner/canned/jira/utils/AbstractTransitionIssue.groovy
com/onresolve/scriptrunner/canned/jira/workflow/postfunctions/TransitionSubTasks.groovy
It goes without saying AbstractTransitionIssue is subclassed multiple times.
One of the intermittent issues is the "Invalid duplicate class definition of class" exception for the AbstractTransitionIssue class. This exception also occasionally occurs for any custom Helper classes within the com/onresolve/scriptrunner/canned/jira/utils/ directory (these methods are statically used). Sometimes it works and sometimes it does not.
Another side effect is loading the admin pages "Builtin scripts" and "Custom Listeners" fails with a message "time out - please see logs".
Usually removing all custom canned scripts from the filesystem directory, restarting JIRA and moving the canned scripts back fixes the issue temporarily. Clearing the Groovy and/or JIRA caches does not clear this issue up.
Any advice would be very helpful.
I've slimmed down the setup to a single class within a single file on the filesystem within the script root /var/atlassian/application-data/jira/scripts. This example class basically subclasses an existing canned script class from the ScriptRunner.
Here are the steps to reproduce this issue:
Place the following file into the file /var/atlassian/application-data/jira/scripts/com/onresolve/scriptrunner/canned/jira/workflow/postfunctions/SubtaskForeach.groovy
package com.onresolve.scriptrunner.canned.jira.workflow.postfunctions public class SubtaskForeach extends CreateSubTask {}
Please note: subclassing another class in the same script root does work as expected.
Spent some more time investigating, it looks like a classloader issue where the Scriptrunner canned scripts are loaded by one classloader, and the custom canned scripts loaded by another, but this second classloader fails to locate the default canned scripts. This may be due to the fact the default canned scripts and the custom canned scripts are in the same package, but in different locations. If this is the case, how can I specify the classpath for the custom canned scripts?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I am fighting the same issue in JIRA 6.2.1. I have found that if I restart JIRA and load the Built In Scripts page before I load the Scripts Listener page they will both load. I tracked it down to one of our custom scripts being defined as a script listener as well. Once I removed any listener configurations using the custom script the Script Listener page would load every time.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Strangely enough, we upgraded to JIRA 6.4.2, removed and recreated the listeners and the issue is no longer present.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I think that must be a configuration issue, because I do this kind of thing hundreds of times a day. Is there some minimal set of classes that you can zip up so that I can try to reproduce?
What are your script roots... are these files in a scripts plugin as well as under a script root?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.