ClassNotFoundException while resolving META-INF/services within V2 Plugins
*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.
We have coded some groovy conditions. When we use a saved filter gadget, a ClassNotFoundException is thrown. The java.util.ServiceLoader uses the Thread Context Class Loader to relsove the service implementation. As fare as I know OSGi or V2 Plugins the OSGi Spec does not define what will be provided by the Thread Context Classloader.... this might be root of the problem.
Hrm. I have seen similar errors recently when developing, then I tried to reproduce it but could not. I feel like I'm homing in on this one though.
I would use groovy 1.7.4 at a minimum, there seems to be some problem with generics in 1.7.3 anyway - GRV-24.
Thanks for letting me know about this anyway.
In 126.96.36.199 the problem does not occour anymore... no idea what Jamie has changed to make the stuff working.
I just did a test with a fresh jira 4.1.1 (JIRA 4.1.1-#522)
You may do the follwing steps to reproduce the problem
Add groovyruner-1.6.jar and groovy-all-1.7.3.jar to WEB-INF/lib
Create a file with following content
Clone jira standard worklow add a the groovy condition specified above to the start-progress transition
Create a workflow scheme using the modified workflow
Create a new jira project using the workflow scheme created in the previous step
Create an issue in this project
Create a filter for all issues in the created project
Create a filter results gadget using the new filter in a dasboard
Click on the workflow actions button in the gadget for newly created issue....
... and you will get the error
When I find some more time, I will run a debugger to analyze the problem.... but this could take some time.
Groovyrunner 1.1 creates the groovy script interpreter directly. In case of Groovyrunner 1.6 the script interpreter is created indirectly by the java scripting infrastructure.
The problem only appears only in case the groovy stuff is created indirectly by java scripting infrastructure
When the available workflow actions are rendered in the gadget a rest webservice call is made. The rest module is a v2 plugin type. So the WorkflowUtils are called from within the OSGi infrastructure. In case the stuff is calculated by the xwork action, there might a different class loader hierarchy. I assume that the ThreadContext Classloader in case of OSGi is not correct anymore when the services defined in groovy-all-x.y.z.jar#META-INF/services are resolved.
When I find some more time, I will do some tests to isolate the problem. But this could take some time because I have some other nuts to crack first.
Also I don't know if WorkflowUtils comes from a v2 plugin, if it does that might not work. However I think you get a different error message.