Where to place .groovy file for custom Groovy listener

[David Conradie]

Rather embarrassed to have to ask this, but here goes anyway.

We're in the process of upgrading from JIRA4.2 with Script Runner 1.7.13 to JIRA5.2.8 with Script Runner 2.13.

On our v4.x environment we have a custom Groovy listener - it works beautifully. It has a package name of com.some.package* so it is located in /opt/jira/atlassian-jira/WEB-INF/classes/com/some/package*

* name changed to protect the innocent, but you get the general idea

The v4.x environment is a standalone JIRA build.

On our v5.x test environment, which is the WAR build, the listener will not load when I add it under Script Runner > Script Listeners > Custom Listener. I started out with the listener's .groovy file - let's call it Class.groovy - in /opt/jira/webapp/WEB-INF/classes/com/some/package but when I plug in the fully-qualified class name com.some.package.Class and click Next, I get a "Problem loading class" error.

I keep staring at the documentation which says "Copy the .groovy file to the correct place under the classes directory (depending on its package)." - I'm not absolutely certain I've got the correct classes directory for this JIRA build type, but I've certainly tried every combination I can think of, and no joy.

So I'm missing something, anyone know what it is?!

[David Conradie · Accepted solution]

OK, problem solved; I knew I was right to be embarrassed to have to post the question, because it was all due to a fundamental misunderstanding on my part of how the WAR build works. A colleague has now put me straight, and now the .groovy file is where it's supposed to be, and is loading.

Many thanks to all for your assistance.

[Darly Senecal-Baptiste]

Hi David:

Since you are saving the script for a WAR build version of JIRA, I want to know, where is the best way to save it?

Thanks

[Anand Unadkat]

Hi David, where did you end up putting the groovy script, i am getting the same error.

Thanks

[Robert Poldervaart]

I put a groovy file with a groovy listener class in my own directory (JiraScripts), outside the JIRA installation, and set the following in the bin/setenv.sh file. Use the -D option in the JAVA_OPTS setting.

export JAVA_OPTS="-Djira.jelly.on=true ${JAVA_OPTS} -Dplugin.resource.directories=/users/atlassian/Documents/JiraScripts"

Then, I was able to define the listener by the class name alone.

[David Conradie]

@Darly - apologies for the delay in responding.

I had to place the .groovy class files in <jira-install-directory>/edit-webapp/WEB-INF/classes/path/for/class's/package , then build the WAR, and restart JIRA. The build script takes care of copying the .groovy file into the correct location (including the subdirectories for the class's package) in the running web app.

[Darly Senecal-Baptiste]

Thanks, David for the help. I realized where atlassian-sdk sets the install directory

[JamieA]

I don't think this has changed... it will change at some point because keeping the classes on the classpath is not very maintainable - you forget when you upgrade.

I presume jira is definitely running out of /opt/jira/webapp ? The war file is not being unpacked each time you start tomcat or something?

[David Conradie]

Hi Jamie, thanks for the swift response. I believe our instance *is* running out of /opt/jira/webapp, but I didn't actually install it; just so I can be sure I'm looking in the right place, would you be able to say how you'd check/prove it?

Dumb question time: any chance the classpath needs a tweak? In our JIRA4 instance, classpath is listed (via 'ps aux') as:

-classpath :/opt/jira-reaction/bin/bootstrap.jar

Whereas in JIRA5 is listed as:

-classpath /opt/tomcat7/bin/bootstrap.jar:/opt/tomcat7/bin/tomcat-juli.jar

Is that leading ":" in the JIRA4 path super-significant?

[Harry Chan]

The ":" is a separator, it's actually multiple paths there

[David Conradie]

Thanks Harry, I was aware of that, just a bit fuzzy about how to interpret a classpath that *begins* with a separator...

Some Googling tells me the Tomcat class loading process has been changing from version to version, so the classpath shown in a JIRA4 instance was always likely to be different from that in JIRA5.

However I did try something hinted at in this post, and tweaked the /opt/tomcat7/conf/catalina.properties file by adding a path to the shared.loader directive:

shared.loader=/opt/jira/scripts

I then placed my listener class file (classname com.some.package.SampleListener) in /opt/jira/scripts/com/some/package

But got this error when trying to configure the listener:

Problem loading class: startup failed: /opt/jira/scripts/com/some/package/SampleListener.groovy: 3: unable to resolve class AbstractIssueEventListener @ line 3, column 1. class SampleListener extends AbstractIssueEventListener { ^ /opt/jira/scripts/com/some/package/SampleListener.groovy: 7: unable to resolve class IssueEvent @ line 7, column 24. void workflowEvent(IssueEvent event) { ^ 2 errors

So the tweak to the shared loader has made my SampleListener loadable/visible, but the standard JIRA classes are no longer loadable. But this does at least confirm it's the class path at fault.

[JamieA]

I don't think you want to modify the shared loader. You can get the tomcat dir by running the following script in the console:

System.getProperty("catalina.home")

should also be available in System Info come to think of it.

I'm a bit puzzed by the compilation error - I would have thought it woud choke on the "import" line if it was going to. Can you post the class to gist.github.com and provide a link?