java.lang.InstantiationException

tip

This happens when you try to instantiate a class that can't be instantiated, either because the class object is abstract, an interface, an array class, a primitive type, void, or because the class has no nullary constructor.

You have a different solution? A short tip here would help you and many other 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,
  • GitHub comment 32#6733959
    via GitHub by marioosh-net
    ,
  • Getting started with ReST
    via by akhil achuthan,
  • Hibernate DAO factory cannot instantiate dao
    via Stack Overflow by m4ri0
    ,
    • 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)

    Users with the same issue

    Unknown visitor1 times, last one,
    Unknown visitor1 times, last one,
    Unknown visitor1 times, last one,
    Unknown visitor1 times, last one,
    Unknown visitor2 times, last one,
    38 more bugmates