java.lang.NoSuchMethodException

There are no available Samebug tips for this exception. Do you have an idea how to solve this issue? A short tip would help users who saw this issue last week.

  • 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: {noformat} java.lang.NoSuchMethodException: Unable to load action: com.atlassian.confluence.plugin.test.TestAction at com.opensymphony.xwork.config.entities.ActionConfig.getMethod(ActionConfig.java:115) at com.atlassian.confluence.security.websudo.WebSudoInterceptor.intercept(WebSudoInterceptor.java:49) {noformat} 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. ----- h5. Technical notes If you debug this, you see an InstantiationException like this: {noformat} java.lang.InstantiationException: com.atlassian.confluence.plugin.test.TestAction at java.lang.Class.newInstance0(Class.java:340) at java.lang.Class.newInstance(Class.java:308) at com.opensymphony.xwork.ObjectFactory.buildBean(ObjectFactory.java:97) at com.opensymphony.xwork.ObjectFactory.buildAction(ObjectFactory.java:77) at com.atlassian.confluence.plugin.ConfluencePluginObjectFactory.buildAction(ConfluencePluginObjectFactory.java:60) {noformat} 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. {code:java} if (!getWebSudoManager().matches(requestURI, actionInvocation.getAction().getClass(), actionInvocation.getProxy().getConfig().getMethod())) return actionInvocation.invoke(); {code} Here is the implementation of getMethod() from ActionConfig which is called above: {code:java} try { ActionConfig actionConfig = new ActionConfig(null, getClassName(), null, null, null); Action action = ObjectFactory.getObjectFactory().buildAction(actionConfig); clazz = action.getClass(); } catch (Exception e) { // TODO: Only doing this because buildAction() throws Exception throw new NoSuchMethodException("Unable to load action: " + e.getMessage()); } {code} 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.
    via by Matt Ryall,
  • 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: {noformat} java.lang.NoSuchMethodException: Unable to load action: com.atlassian.confluence.plugin.test.TestAction at com.opensymphony.xwork.config.entities.ActionConfig.getMethod(ActionConfig.java:115) at com.atlassian.confluence.security.websudo.WebSudoInterceptor.intercept(WebSudoInterceptor.java:49) {noformat} 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. ----- h5. Technical notes If you debug this, you see an InstantiationException like this: {noformat} java.lang.InstantiationException: com.atlassian.confluence.plugin.test.TestAction at java.lang.Class.newInstance0(Class.java:340) at java.lang.Class.newInstance(Class.java:308) at com.opensymphony.xwork.ObjectFactory.buildBean(ObjectFactory.java:97) at com.opensymphony.xwork.ObjectFactory.buildAction(ObjectFactory.java:77) at com.atlassian.confluence.plugin.ConfluencePluginObjectFactory.buildAction(ConfluencePluginObjectFactory.java:60) {noformat} 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. {code:java} if (!getWebSudoManager().matches(requestURI, actionInvocation.getAction().getClass(), actionInvocation.getProxy().getConfig().getMethod())) return actionInvocation.invoke(); {code} Here is the implementation of getMethod() from ActionConfig which is called above: {code:java} try { ActionConfig actionConfig = new ActionConfig(null, getClassName(), null, null, null); Action action = ObjectFactory.getObjectFactory().buildAction(actionConfig); clazz = action.getClass(); } catch (Exception e) { // TODO: Only doing this because buildAction() throws Exception throw new NoSuchMethodException("Unable to load action: " + e.getMessage()); } {code} 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.
    via by Matt Ryall,
  • atlassian-plugin.xml {noformat} <xwork name="Custom Attach" key="custom-attach"> <description>Provides custom attach file action that works with Crowd's SSO.</description> <package name="custom-attach" extends="default" namespace="/screensnipe-custom-attach"> <default-interceptor-ref name="validatingStack"/> <action name="attach-file" class="com.screensnipe.confluence.atlassian.CustomAttachFile"> <result name="input" type="json"/> <result name="json" type="json"/> <result name="error" type="json"/> <result name="notpermitted" type="json"/> </action> </package> </xwork> {noformat} The exception: {noformat} java.lang.NoSuchMethodException: Unable to load action: com.screensnipe.confluence.atlassian.CustomAttachFile at com.opensymphony.xwork.config.entities.ActionConfig.getMethod(ActionConfig.java:115) at com.atlassian.xwork.interceptors.XsrfTokenInterceptor.intercept(XsrfTokenInterceptor.java:78) at com.atlassian.confluence.xwork.ConfluenceXsrfTokenInterceptor.intercept(ConfluenceXsrfTokenInterceptor.java:25) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:165) at com.atlassian.confluence.security.interceptors.CaptchaInterceptor.intercept(CaptchaInterceptor.java:46) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:165) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:35) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:165) at com.atlassian.confluence.util.LoggingContextInterceptor.intercept(LoggingContextInterceptor.java:49) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:165) at com.atlassian.confluence.core.CancellingInterceptor.intercept(CancellingInterceptor.java:23) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:165) {noformat} Actually, there should be "caused by" but you didn't chain the exception. ActionConfig, line 114-115: catch (Exception e) { throw new NoSuchMethodException("Unable to load action: " + e.getMessage()); (lost cause) {noformat} [INFO] [talledLocalContainer] java.lang.InstantiationException: com.screensnipe.confluence.atlassian.CustomAttachFile [INFO] [talledLocalContainer] at java.lang.Class.newInstance0(Class.java:340) [INFO] [talledLocalContainer] at java.lang.Class.newInstance(Class.java:308) [INFO] [talledLocalContainer] at com.opensymphony.xwork.ObjectFactory.buildBean(ObjectFactory.java:97) [INFO] [talledLocalContainer] at com.opensymphony.xwork.ObjectFactory.buildAction(ObjectFactory.java:77) [INFO] [talledLocalContainer] at com.atlassian.confluence.plugin.ConfluencePluginObjectFactory.buildAction(ConfluencePluginObjectFactory.java:60) [INFO] [talledLocalContainer] at com.opensymphony.xwork.config.entities.ActionConfig.getMethod(ActionConfig.java:112) {noformat} See CONF-20055 - it's *just the same* problem with another interceptor. XSRF Interceptor needs to instantiate action just to check the annotations. It does it by calling Class.newInstance(). In our company, we use constructor-based injection. For details, see CONF-20055.
    via by Damian Nowak,
  • atlassian-plugin.xml {noformat} <xwork name="Custom Attach" key="custom-attach"> <description>Provides custom attach file action that works with Crowd's SSO.</description> <package name="custom-attach" extends="default" namespace="/screensnipe-custom-attach"> <default-interceptor-ref name="validatingStack"/> <action name="attach-file" class="com.screensnipe.confluence.atlassian.CustomAttachFile"> <result name="input" type="json"/> <result name="json" type="json"/> <result name="error" type="json"/> <result name="notpermitted" type="json"/> </action> </package> </xwork> {noformat} The exception: {noformat} java.lang.NoSuchMethodException: Unable to load action: com.screensnipe.confluence.atlassian.CustomAttachFile at com.opensymphony.xwork.config.entities.ActionConfig.getMethod(ActionConfig.java:115) at com.atlassian.xwork.interceptors.XsrfTokenInterceptor.intercept(XsrfTokenInterceptor.java:78) at com.atlassian.confluence.xwork.ConfluenceXsrfTokenInterceptor.intercept(ConfluenceXsrfTokenInterceptor.java:25) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:165) at com.atlassian.confluence.security.interceptors.CaptchaInterceptor.intercept(CaptchaInterceptor.java:46) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:165) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:35) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:165) at com.atlassian.confluence.util.LoggingContextInterceptor.intercept(LoggingContextInterceptor.java:49) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:165) at com.atlassian.confluence.core.CancellingInterceptor.intercept(CancellingInterceptor.java:23) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:165) {noformat} Actually, there should be "caused by" but you didn't chain the exception. ActionConfig, line 114-115: catch (Exception e) { throw new NoSuchMethodException("Unable to load action: " + e.getMessage()); (lost cause) {noformat} [INFO] [talledLocalContainer] java.lang.InstantiationException: com.screensnipe.confluence.atlassian.CustomAttachFile [INFO] [talledLocalContainer] at java.lang.Class.newInstance0(Class.java:340) [INFO] [talledLocalContainer] at java.lang.Class.newInstance(Class.java:308) [INFO] [talledLocalContainer] at com.opensymphony.xwork.ObjectFactory.buildBean(ObjectFactory.java:97) [INFO] [talledLocalContainer] at com.opensymphony.xwork.ObjectFactory.buildAction(ObjectFactory.java:77) [INFO] [talledLocalContainer] at com.atlassian.confluence.plugin.ConfluencePluginObjectFactory.buildAction(ConfluencePluginObjectFactory.java:60) [INFO] [talledLocalContainer] at com.opensymphony.xwork.config.entities.ActionConfig.getMethod(ActionConfig.java:112) {noformat} See CONF-20055 - it's *just the same* problem with another interceptor. XSRF Interceptor needs to instantiate action just to check the annotations. It does it by calling Class.newInstance(). In our company, we use constructor-based injection. For details, see CONF-20055.
    via by Damian Nowak,
    • java.lang.NoSuchMethodException: Unable to load action: com.atlassian.confluence.plugin.test.TestAction at com.opensymphony.xwork.config.entities.ActionConfig.getMethod(ActionConfig.java:115) at com.atlassian.confluence.security.websudo.WebSudoInterceptor.intercept(WebSudoInterceptor.java:49)
    No Bugmate found.