java.lang.InstantiationException: gobblin.writer.AvroHdfsDataWriter

Google Groups | RG | 1 year ago
tip
Do you find the tips below useful? Click on the to mark them and say thanks to rafael . Or join the community to write better ones.
  1. 0

    Job running successfully but Custom kafka bytes to avro extractor not working

    Google Groups | 1 year ago | RG
    java.lang.InstantiationException: gobblin.writer.AvroHdfsDataWriter
  2. 0
    samebug 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.
  3. 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 | 7 years ago | Matt Ryall
    java.lang.InstantiationException: com.atlassian.confluence.plugin.test.TestAction
  4. Speed up your debug routine!

    Automated exception search integrated into your IDE

  5. 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 | 7 years ago | Matt Ryall
    java.lang.InstantiationException: com.atlassian.confluence.plugin.test.TestAction
  6. 0

    GitHub comment 9463#163855089

    GitHub | 1 year ago | satshil
    java.lang.InstantiationException: org.springframework.boot.actuate.autoconfigure.EndpointWebMvcAutoConfiguration$ApplicationContextHeaderFilter

  1. osvzs 1 times, last 3 weeks ago
  2. Andreas Häber 2 times, last 4 weeks ago
  3. filpgame 8 times, last 3 months ago
  4. tzrlk 1 times, last 6 months ago
  5. lribeiro 2 times, last 8 months ago
9 more registered users
45 unregistered visitors
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.InstantiationException

    gobblin.writer.AvroHdfsDataWriter

    at java.lang.Class.newInstance()
  2. Java RT
    Class.newInstance
    1. java.lang.Class.newInstance(Class.java:368)
    1 frame
  3. gobblin.runtime
    Fork.run
    1. gobblin.runtime.TaskContext.getDataWriterBuilder(TaskContext.java:297)
    2. gobblin.runtime.Fork.buildWriter(Fork.java:371)
    3. gobblin.runtime.Fork.buildWriterIfNotPresent(Fork.java:385)
    4. gobblin.runtime.Fork.processRecords(Fork.java:405)
    5. gobblin.runtime.Fork.run(Fork.java:169)
    5 frames
  4. Java RT
    Thread.run
    1. java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
    2. java.util.concurrent.FutureTask.run(FutureTask.java:262)
    3. java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    4. java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    5. java.lang.Thread.run(Thread.java:745)
    5 frames