java.lang.InstantiationException: gobblin.writer.AvroHdfsDataWriter

If you like a tip written by other Samebug users, mark is as helpful! Marks help our algorithm provide you better solutions and also help other users.
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 9463#163855089
    via GitHub by satshil
    ,
  • GitHub comment 9481#165067443
    via GitHub by satshil
    ,
  • Java InstantiationException
    via Stack Overflow by Shobosy
    ,
    • java.lang.InstantiationException: gobblin.writer.AvroHdfsDataWriter at gobblin.runtime.TaskContext.getDataWriterBuilder(TaskContext.java:301) at gobblin.runtime.Fork.buildWriter(Fork.java:371) at gobblin.runtime.Fork.buildWriterIfNotPresent(Fork.java:385) at gobblin.runtime.Fork.processRecords(Fork.java:405) at gobblin.runtime.Fork.run(Fork.java:169) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.InstantiationException: gobblin.writer.AvroHdfsDataWriter at java.lang.Class.newInstance(Class.java:368) at gobblin.runtime.TaskContext.getDataWriterBuilder(TaskContext.java:297) ... 9 more

    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 User
    Unknown User178 times, last one,
    39 more bugmates