*This issue has moved*
This issue has been moved permanently to Adaptavist's Product Support JIRA instance.
All existing users of this instance should have the same username on our Product Support instance. However, you will very likely need to click on the
Can't access your account link in order to reset to a new password.
Right now, you try/catch the call to go, and then print the stack trace.
Now, two lines later you say:
Since ret is not set from the exception, you NPE.
This may have changed somewhat in 1.7. I'm not sure what the issue is here to be honest, are you saying that an exception is swallowed silently? Or that an exception is thrown when it should not be?
If so can you describe more what the issue is and how it affects you/the users.
If there is an exception when creating the scriptenginemanager/factory/etc, "ret" is null. Then, following the catch block, you say if ret.something(), which throws an NPE.
There are 2 bugs here. 1, your plugin should be more graceful than an NPE. 2, there is a bug I have on atlassian about the environment that causes the ScriptEngineManager to throw an exception.
To your point about 1.7, I looked at the code in SVN, its still there.
OK, I will take a look at it. What's the bug that causes ScriptEngMgr to throw?
Latest Jira, jruby, groovyrunner, keyboard shortcuts (press '.'), a condition written in ruby.
The ThreadLocal classloader that is used in ScrEngMan is allowing the loading of the resource that defines jruby as an option, but the classloader is not setup to actually load the class. OSGi fun times.
This doesnt happen when rendering the page in general, but the ajax call to get the actions and options when pressing '.' does not have the same context setup as the page view way.
Aiii... sounds nasty. I had no idea anyone was using it for jruby. Not tested ruby in the latest version, and I had to remove some ruby-specific property. Anyway, you're not using 1.7 so that's not to blame...