java.lang.NoSuchMethodException: Unable to load action: com.atlassian.confluence.plugin.test.TestAction

Atlassian JIRA | Matt Ryall | 6 years ago
  1. 0

    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.

    Atlassian JIRA | 6 years ago | Matt Ryall
    java.lang.NoSuchMethodException: Unable to load action: com.atlassian.confluence.plugin.test.TestAction
  2. 0

    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.

    Atlassian JIRA | 6 years ago | Matt Ryall
    java.lang.NoSuchMethodException: Unable to load action: com.atlassian.confluence.plugin.test.TestAction
  3. 0

    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.

    Atlassian JIRA | 5 years ago | Damian Nowak
    java.lang.NoSuchMethodException: Unable to load action: com.screensnipe.confluence.atlassian.CustomAttachFile
  4. Speed up your debug routine!

    Automated exception search integrated into your IDE

  5. 0

    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.

    Atlassian JIRA | 5 years ago | Damian Nowak
    java.lang.NoSuchMethodException: Unable to load action: com.screensnipe.confluence.atlassian.CustomAttachFile
  6. 0

    {noformat} 2006-12-20 14:42:44,860 ERROR CRCSCU2->IMPAX5018RKKCS (TCPServer-2) [org.dcm4chex.archive.dcm.storescp.StoreScpService] Query for matching worklist entries for received Series[1.2.392.200036.9125.3.112193711940.64508363123.22165187] failed: javax.management.ReflectionException at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:228) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.dcm4chex.archive.dcm.storescp.StoreScpService.findMWLEntries(StoreScpService.java:720) at org.dcm4chex.archive.dcm.storescp.StoreScp.mergeMatchingMWLItem(StoreScp.java:538) at org.dcm4chex.archive.dcm.storescp.StoreScp.doCStore(StoreScp.java:483) at org.dcm4che.net.DcmServiceBase.c_store(DcmServiceBase.java:116) at org.dcm4cheri.net.ActiveAssociationImpl.run(ActiveAssociationImpl.java:215) at org.dcm4cheri.util.LF_ThreadPool.join(LF_ThreadPool.java:174) at org.dcm4cheri.net.ActiveAssociationImpl.run(ActiveAssociationImpl.java:148) at org.dcm4cheri.server.DcmHandlerImpl.handle(DcmHandlerImpl.java:249) at org.dcm4cheri.server.ServerImpl.run(ServerImpl.java:263) at org.dcm4cheri.util.LF_ThreadPool.join(LF_ThreadPool.java:174) at org.dcm4cheri.server.ServerImpl$1.run(ServerImpl.java:217) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.NoSuchMethodException: Unable to find operation findMWLEntries(org.dcm4che.data.Dataset) ... 14 more {noformat} Broken by modification in MWL SCU service by DCMEE-184: Support forward of MWL FIND RQ to external MWL SCU by MWLFindScp.

    JIRA | 10 years ago | Peter Heiles
    javax.management.ReflectionException

    Not finding the right solution?
    Take a tour to get the most out of Samebug.

    Tired of useless tips?

    Automated exception search integrated into your IDE

    Root Cause Analysis

    1. java.lang.NoSuchMethodException

      Unable to load action: com.atlassian.confluence.plugin.test.TestAction

      at com.opensymphony.xwork.config.entities.ActionConfig.getMethod()
    2. com.opensymphony.xwork
      ActionConfig.getMethod
      1. com.opensymphony.xwork.config.entities.ActionConfig.getMethod(ActionConfig.java:115)
      1 frame
    3. com.atlassian.confluence
      WebSudoInterceptor.intercept
      1. com.atlassian.confluence.security.websudo.WebSudoInterceptor.intercept(WebSudoInterceptor.java:49)
      1 frame