Steps to reproduce:
1. Upload test-admin-action-plugin-1.0-SNAPSHOT.jar into Confluence 3.3-beta2.
2. Ensure web sudo is enabled.
3. Go to the test page, e.g. http://localhost:8080/confluence/admin/test/test.action
4. You get the following exception:
5. Disable web sudo.
6. Go to the test page, e.g. http://localhost:8080/confluence/admin/test/test.action
7. The action works if web sudo is disabled.
I'm rating this as critical because it's a regression which will affect many Adaptavist plugins (the bug was discovered by Dan Hardiker). We've been recommending them to use constructor injection for a few years now, so this is a serious problem for them.
If you debug this, you see an InstantiationException like this:
Some code in the WebSudoInterceptor actually results in a new (non-PluginAware) ActionConfig being instantiated by XWork, where the plugin classloader is not used to find the plugin class or autowire it properly.
Here is the implementation of getMethod() from ActionConfig which is called above:
Notice that a new ActionConfig is created here and passed to ConfluencePluginObjectFactory.buildAction(). When this method is called with a non-PluginAware ActionConfig, XWork ends up calling Class.newInstance() which only works for actions which don't use constructor injection.
We need to change the WebSudoInterceptor to use a way of finding the Method that doesn't construct a new ActionConfig object. At this late stage in the release, I think a good start would be copying the mechanism from ActionConfig into the WebSudoInterceptor and use getMethodName() without loading the class this way.